"xs0" <xs0@xs0.com> ??????:e7gddu$26gk$1@digitaldaemon.com...
> 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..
>

Just because these reason.

private a_type var;

public static int func(...)
{
}

this syntax is simple, clean and enough.

>
> xs0

On Fri, 23 Jun 2006 11:20:08 -0400, Ameer Armaly <ameer_armaly@hotmail.com> wrote:

> "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.

I hate it and prefer the : syntax :)

Regan

On Sat, 24 Jun 2006 11:25:19 +1200, Regan Heath <regan@netwin.co.nz> wrote:
> 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.

Here I am talking about within class declarations, for module scope I either use the {} form or if I only have 1 thing or several which are not 'conceptually' grouped I apply protection individually (much like Daniel Keep suggested in his reply to this thread)

Regan

"Andrei Khropov" <andkhropov@nospam_mtu-net.ru> ??????:e7gs64$2ucq$1@digitaldaemon.com...
> 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.
>

In much C++ codes, the declaration and defination of a function is seperated, this is the main reason of colon-like syntax.

Otherwize, in no case can Bjarne Stroustrup make the colon-like syntax.



>
> -- 
> AKhropov

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

>
> "xs0" <xs0@xs0.com> ??????:e7gddu$26gk$1@digitaldaemon.com...
>> 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..
>>
>
> Just because these reason.
>
> private a_type var;
>
> public static int func(...)
> {
> }
>
> this syntax is simple, clean and enough.
>

And this is what ...?

 private a_type var1;
 public static a_type var2;
 public static int func1(...)
 {
 }
 private a_type var3;
 public int func2(...)
 {
 }
 private static int func3(...)
 {
 }
 public a_type var4;
 private a_type var5;
 public static int func4(...)
 {
 }
 private static a_type var6;
 private a_type var7;
 public int func5(...)
 {
 }
 private a_type var8;

 private int func6(...)
 {
 }

Compared to ...

 private {
    static {
       int func3(...)
       {
       }
       a_type var6;
    }
    a_type var1;
    a_type var3;
    a_type var5;
    a_type var7;
    a_type var8;
    int func6(...)
    {
    }
 }

 public {
    static {
       int func1(...)
       {
       }
       int func4(...)
       {
       }
       a_type var2;
    }
    int func2(...)
    {
    }
    a_type var4;
    int func5(...)
    {
    }
}


-- 
Derek Parnell
Melbourne, Australia

"Daniel Keep" <daniel.keep.list@gmail.com> ??????:e7grur$2tq6$1@digitaldaemon.com...
> 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.
>
NO,NO. I am a programmer of C ,about fifteen years. i like C.


> 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.
>

The key is that your's pleasure is the suffering of other people!

> 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

And this is what ?

>
>       // six pages
>      ...
>
>        int func3(...)
>        {
>        }
>        int func4(...)
>        {
>        }
>        int func5(...)
>        {
>        }
>        int func6(...)
>        {
>        }
>        int func7(...)
>        {
>        }
>        a_type var2;
>     }
>     int func2(...)
>     {
>     }
>     a_type var4;
>     int func5(...)
>     {
>     }
> }

"Derek Parnell" <derek@psych.ward> дÈëÏûÏ¢ÐÂÎÅ:op.tbmhl9lt6b8z09@ginger.vic.bigpond.net.au...
> On Fri, 23 Jun 2006 21:21:35 +1000, Boris Wang <nano.kago@hotmail.com> wrote:
>
>>
>> "xs0" <xs0@xs0.com> ??????:e7gddu$26gk$1@digitaldaemon.com...
>>> 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..
>>>
>>
>> Just because these reason.
>>
>> private a_type var;
>>
>> public static int func(...)
>> {
>> }
>>
>> this syntax is simple, clean and enough.
>>
>
> And this is what ...?
>
>  private a_type var1;
>  public static a_type var2;
>  public static int func1(...)
>  {
>  }
>  private a_type var3;
>  public int func2(...)
>  {
>  }
>  private static int func3(...)
>  {
>  }
>  public a_type var4;
>  private a_type var5;
>  public static int func4(...)
>  {
>  }
>  private static a_type var6;
>  private a_type var7;
>  public int func5(...)
>  {
>  }
>  private a_type var8;
>
>  private int func6(...)
>  {
>  }
>
> Compared to ...
>
>  private {
>     static {
>        int func3(...)
>        {
>        }
>        a_type var6;
>     }
>     a_type var1;
>     a_type var3;
>     a_type var5;
>     a_type var7;
>     a_type var8;
>     int func6(...)
>     {
>     }
>  }
>
>  public {
>     static {
>        int func1(...)
>        {
>        }
>        int func4(...)
>        {
>        }
>        a_type var2;
>     }
>     int func2(...)
>     {
>     }
>     a_type var4;
>     int func5(...)
>     {
>     }
> }
>
>
> -- 
> Derek Parnell
> Melbourne, Australia

On Sat, 24 Jun 2006 10:22:00 +1000, Boris Wang <nano.kago@hotmail.com> wrote:

> And this is what ?
>
>>
>>       // six pages
>>      ...
>>
>>        int func3(...)
>>        {
>>        }
>>        int func4(...)
>>        {
>>        }
>>        int func5(...)
>>        {
>>        }
>>        int func6(...)
>>        {
>>        }
>>        int func7(...)
>>        {
>>        }
>>        a_type var2;
>>     }
>>     int func2(...)
>>     {
>>     }
>>     a_type var4;
>>     int func5(...)
>>     {
>>     }
>> }

Excellent, that is what it is. To find out whether it is public/private/static/version/debug effected, place your cursor on the final "}" and press ctrl-[ to jump to the matching brace. This assumes you are using Crimson Editor of course ;-)

The point is, writing organised and predicatable code is less costly in the long run. We also have access to tools (i.e good editors) that can help us.

-- 
Derek Parnell
Melbourne, Australia

"Regan Heath" <regan@netwin.co.nz> wrote in message news:optbmgr7jt23k2f5@nrage...

> I hate it and prefer the : syntax :)

Then turn off static with the : syntax ;)

On Sat, 24 Jun 2006 07:43:26 +0800, Boris Wang <nano.kago@hotmail.com> wrote:
> "Andrei Khropov" <andkhropov@nospam_mtu-net.ru>
> ??????:e7gs64$2ucq$1@digitaldaemon.com...
>> 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.
>>
>
> In much C++ codes, the declaration and defination of a function is
> seperated, this is the main reason of colon-like syntax.
>
> Otherwize, in no case can Bjarne Stroustrup make the colon-like syntax.

I don't think you can make that assertion.

Like several people have said both the : and {} syntax are useful to group things together. That alone is reason enough to use them in C++ and indeed that is why/how I use them.

Like Derek has just shown (to my mind) the {} syntax makes a cleaner, easier to read example, and further many editors will help further by highlighting/finding and collapsing blocks declared with either : or {} something that simply isn't possible if you specify them all in every case.

Regan