the harm of these is more than the benefit.

all these syntax produce non-readable, non-maintainable codes, and even more in large project with many developers.

On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago@hotmail.com> wrote:
> the harm of these is more than the benefit.
>
> all these syntax produce non-readable, non-maintainable codes, and even more in large project with many developers.

My vote is against removing these. I use them and prefer the : syntax for private etc within class/struct declarations.

Regan

Regan Heath wrote:
> On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago@hotmail.com> wrote:
>> the harm of these is more than the benefit.
>>
>> all these syntax produce non-readable, non-maintainable codes, and even more in large project with many developers.
> 
> My vote is against removing these. I use them and prefer the : syntax for private etc within class/struct declarations.

My vote is against having either public: or public {} :)

With both you can't see what applies to a declaration from the declaration alone, but have to scan backwards for an arbitrary amount of lines..


xs0

On Fri, 23 Jun 2006 19:05:15 +1000, Boris Wang <nano.kago@hotmail.com> wrote:

> the harm of these is more than the benefit.

Why?

> all these syntax produce non-readable, non-maintainable codes, and even more in large project with many developers.

Have you evidence or rationale for that position?

I would argue strongly against removing these. My preference is to avoid the ':' form and nearly always use the '{}' form. I use the 'public' option as a documentation tool plus I hope that one day the 'private' option will be the default.

-- 
Derek Parnell
Melbourne, Australia

Boris Wang wrote:
> the harm of these is more than the benefit.

I disagree. I like them and do not want to see them go away.

> 
> all these syntax produce non-readable, non-maintainable codes, and even more in large project with many developers. 
> 
> 
That's why large teams have coding standards. If you are going to work on a large project and something is unreadable to you, make sure your coding standards prohibit it. You'll still have to deal with it when modifying third party code, but there's nothing you can do about it.

I find the syntax quite readable and have no trouble with it. So I strongly appeal that it not be removed.

Boris Wang wrote:
> the harm of these is more than the benefit.
> 
> all these syntax produce non-readable, non-maintainable codes, and even more in large project with many developers. 

Have you seen the International Obfuscated C Code Competition?  By your rationale, then the entire C language is evil, and thus by extension, most of D is evil.  Given enough time and incentive, you can write totally unreadable code in almost anything.

Can you abuse "protection:" and "protection{}"?  Of course you can!  But that's not the point.  You can abuse aliases as well.  You can abuse pointers.  You can abuse arrays and hashes.  You can abuse the ability to choose your own variable names, operator overloading, classes, functions... just about anything.

Just because you don't agree with something, can't immediately see its benefit, or can't use it properly yourself doesn't mean it should be removed.

I personally use all three forms.  I habitually divide my classes into clear sections based on who is using them.  Public section first so people can read the top of the class for a quick reference, protected next for people overriding the class, and public last for internal details.  Marking each one seperately would be a pain, and the off-side "public:", "protected:" and "private:" help delineate the sections.

I use the braces form for, for example, grouping together small bunches of declarations at module level.  When I write my module imports, they look like this:

# private
# {
#     import first.module;
#     import second.module;
# }

Should I be forced to write all these out long-hand because you don't like that form?  You claim that these produce unreadable code, and whilst they COULD be abused, they also help me keep MY code more organised.

Should we have all Perl coders shot on sight?  Don't be silly :)

Regards,

	-- Daniel

Mike Parker wrote:

> Boris Wang wrote:
> > the harm of these is more than the benefit.
> 
> I disagree. I like them and do not want to see them go away.
> 
> > 
> > all these syntax produce non-readable, non-maintainable codes, and even more  in large project with many developers.
> That's why large teams have coding standards. If you are going to work on a large project and something is unreadable to you, make sure your coding standards prohibit it. You'll still have to deal with it when modifying third party code, but there's nothing you can do about it.
> 
> I find the syntax quite readable and have no trouble with it. So I strongly appeal that it not be removed.

I agree with you.
I always like C++ way of declaring members instead of Java/C# way because
"public:" and "private:" sections visually separate interface and
implementation.
And if you want you can always establish coding standards for either option.


-- 
AKhropov

"Boris Wang" <nano.kago@hotmail.com> wrote in message news:e7gau0$22li$1@digitaldaemon.com...
> the harm of these is more than the benefit.
>
> all these syntax produce non-readable, non-maintainable codes, and even more in large project with many developers.

While I agree with your argument and personally always use per-member protection, other people obviously still like the other methods.

What might be a bit of a compromise would be to get rid of : and keep {}, since : has some issues (how do you turn off static, for example?).  {} at least introduces a sort of "segment" of code, and makes it possible to see when the attributes end.  With good indentation, and a good text editor, you can always find what protectection and storage class something is.

class A
{
    // The public "segment"
    public
    {
        method
        field..
        blah
    }

    // Any public static fields
    public static
    {

    }

    // Hidden stuff
    protected
    {

    }
}

Not that terrible.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:e7gsnn$2vhj$1@digitaldaemon.com...
> "Boris Wang" <nano.kago@hotmail.com> wrote in message news:e7gau0$22li$1@digitaldaemon.com...
>> the harm of these is more than the benefit.
>>
>> all these syntax produce non-readable, non-maintainable codes, and even more in large project with many developers.
>
> While I agree with your argument and personally always use per-member protection, other people obviously still like the other methods.
>
> What might be a bit of a compromise would be to get rid of : and keep {}, since : has some issues (how do you turn off static, for example?).  {} at least introduces a sort of "segment" of code, and makes it possible to see when the attributes end.  With good indentation, and a good text editor, you can always find what protectection and storage class something is.
>
> class A
> {
>    // The public "segment"
>    public
>    {
>        method
>        field..
>        blah
>    }
>
>    // Any public static fields
>    public static
>    {
>
>    }
>
>    // Hidden stuff
>    protected
>    {
>
>    }
> }
>
> Not that terrible.
I like it.  It's much more direct than using : syntax IMO.
 >
> 

On Fri, 23 Jun 2006 11:48:57 +0200, xs0 <xs0@xs0.com> wrote:
> Regan Heath wrote:
>> On Fri, 23 Jun 2006 17:05:15 +0800, Boris Wang <nano.kago@hotmail.com> wrote:
>>> the harm of these is more than the benefit.
>>>
>>> all these syntax produce non-readable, non-maintainable codes, and even more in large project with many developers.
>>  My vote is against removing these. I use them and prefer the : syntax for private etc within class/struct declarations.
>
> My vote is against having either public: or public {} :)
>
> With both you can't see what applies to a declaration from the declaration alone, but have to scan backwards for an arbitrary amount of lines..

That doesn't bother me in the slightest (which is why I don't want them removed). I simply group all the public, protected and private methods together and use the : syntax. I can mostly tell from method name and context which access specifier any given function has (or should have) and the syntax is mostly for the compiler benefit, not mine. I definately do not want to have to put private etc in front of every single function declaration.

Regan