www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - appeal again: discard the syntax of private:, public: static: private{}, public{}, static{}.

reply "Boris Wang" <nano.kago hotmail.com> writes:
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. 
Jun 23 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jun 23 2006
parent reply xs0 <xs0 xs0.com> writes:
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
Jun 23 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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.

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
Jun 23 2006
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
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.

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
Jun 23 2006
prev sibling parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"Regan Heath" <regan netwin.co.nz> ??????:optbmgohdr23k2f5 nrage...
 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.

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

There are many coding style here already! Please remember, we must speek English here for communion, and not the mother-language of you. D should be a professional language for all the programmer, not a toy of someone. At last, there is no heaven for everyone.
Jun 23 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 24 Jun 2006 08:36:52 +0800, Boris Wang <nano.kago hotmail.com>  
wrote:
 "Regan Heath" <regan netwin.co.nz> ??????:optbmgohdr23k2f5 nrage...
 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.

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

There are many coding style here already! Please remember, we must speek English here for communion, and not the mother-language of you. D should be a professional language for all the programmer, not a toy of someone. At last, there is no heaven for everyone.

Sorry, I don't understand what you're trying to say. Regan
Jun 24 2006
prev sibling parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"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 

Jun 23 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
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
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
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

Jun 23 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
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
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
What you said is that, i can't has a good feeling about reading your 
program, just because i has not such  a editor?

In other words, you force the other readers to use the editor you use?

"Derek Parnell" <derek psych.ward>
写入消息新闻:op.tbml4bwn6b8z09 ginger.vic.bigpond.net.au...
 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

Jun 24 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 24 Jun 2006 18:39:54 +0800, Boris Wang <nano.kago hotmail.com>  
wrote:
 What you said is that, i can't has a good feeling about reading your
 program, just because i has not such  a editor?

 In other words, you force the other readers to use the editor you use?

How is that any different to you forcing people to code using the forms you prefer? Even without an editor that collapses : and {} I find Dereks example easier to read. Regan
 "Derek Parnell" <derek psych.ward> 脨 
 麓脠毛脧没脧垄脨脗脦脜:op.tbml4bwn6b8z09 ginger.vic.bigpond.net.au...
 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


Jun 24 2006
prev sibling next sibling parent "Derek Parnell" <derek psych.ward> writes:
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
Jun 23 2006
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
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. 
 
 

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.
Jun 23 2006
parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
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.

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
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"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.

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 

Jun 23 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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  

 more  in large project with many developers.

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
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
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(...)
     {
     }
 }

If you can make a good enough solution for this problem, i'll give up.
 private int var;

 public int func( .. )
{
}

this syntax has no other problem, except that some people don't like it. The codes of mango project is more beatiful than the others i readed. "Regan Heath" <regan netwin.co.nz> ??????:optbmn7svj23k2f5 nrage...
 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

 more  in large project with many developers.

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

Jun 24 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 24 Jun 2006 20:52:08 +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(...)
     {
     }
 }

If you can make a good enough solution for this problem, i'll give up.

The problem you highlight with this example does not go away with either style of coding, because without seeing the code at the matching open brace, you can't tell what the scope of the contents is. For example, your example could begin with ... private void xfunc() { making all the functions nested and thus sort of private. Without actually looking, you can't tell from just seeing the end of a braced code snippet.
 private int var;

 public int func( .. )
 {
 }

this syntax has no other problem, except that some people don't like it.

Oh well! Get used to the idea of free choice. Coders have been given the opportunity to code using the style that find helpful or best expresses their frame of mind. And that is not intrinsically a bad thing. I won't force my style on you and I expect that you won't force your style on me, okay?
 The codes of mango project is more beatiful than the others i readed.

Yes, it is lovely code and easy to read. Well done Mango team. A lot of that has got to do with adhering to coding standards regardless of what those standards are. -- Derek Parnell Melbourne, Australia
Jun 24 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"Derek Parnell" <derek psych.ward>
写入消息新闻:op.tbndxng06b8z09 ginger.vic.bigpond.net.au...
 On Sat, 24 Jun 2006 20:52:08 +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(...)
     {
     }
 }

If you can make a good enough solution for this problem, i'll give up.

The problem you highlight with this example does not go away with either style of coding, because without seeing the code at the matching open brace, you can't tell what the scope of the contents is. For example, your example could begin with ... private void xfunc() { making all the functions nested and thus sort of private. Without actually looking, you can't tell from just seeing the end of a braced code snippet.
 private int var;

 public int func( .. )
 {
 }

this syntax has no other problem, except that some people don't like it.

Oh well! Get used to the idea of free choice. Coders have been given the opportunity to code using the style that find helpful or best expresses their frame of mind. And that is not intrinsically a bad thing. I won't force my style on you and I expect that you won't force your style on me, okay?

I don't dislike each style syntax, except the problem i talk about. What we discussed here, is not what you like or i like, if you really love D.
 The codes of mango project is more beatiful than the others i readed.

Yes, it is lovely code and easy to read. Well done Mango team. A lot of that has got to do with adhering to coding standards regardless of what those standards are.

Hmm, you have admit that the syntax without colon and curly braces can produce readable and maintainable codes. But, the syntax with colon or curly braces, has the problem of expansibility.
 -- 
 Derek Parnell
 Melbourne, Australia 

Jun 24 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Sun, 25 Jun 2006 12:28:40 +1000, Boris Wang <nano.kago hotmail.com>  
wrote:

 The codes of mango project is more beatiful than the others i readed.

Yes, it is lovely code and easy to read. Well done Mango team. A lot of that has got to do with adhering to coding standards regardless of what those standards are.

Hmm, you have admit that the syntax without colon and curly braces can produce readable and maintainable codes.

Yes it can, inspite of being a poorer choice. Just think how much nicer the code could be if they used the alternative coding sytle. -- Derek Parnell Melbourne, Australia
Jun 24 2006
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 24 Jun 2006 18:52:08 +0800, Boris Wang <nano.kago hotmail.com>  
wrote:
 And this is what ?

In Dereks example the protection attribute applied to all 6 pages is the one written above them, that attribute is simple to find, and simple to remember while reading the latter 6 pages. I find it far easier to read than: 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(...) { } where I have to filter out all the redundant 'private' etc text in order to see the _actual_ code, the code which actually does something.
 If you can make a good enough solution for this problem, i'll give up.

Dereks example is how _I_ (and Derek perhaps) would write it, the code above is how _you_ would write it. Neither form is _incorrect_ it's simply a matter of personal preference.
 private int var;

 public int func( .. )
 {
 }

this syntax has no other problem, except that some people don't like it.

This syntax forces the use of redundant 'public' etc text, which _I_ find clutters the view and obscures and obfuscates the important parts of the code.
 The codes of mango project is more beatiful than the others i readed.

Each to their own (which is the point I am trying to make). Regan
Jun 24 2006
parent reply Ben Phillips <Ben_member pathlink.com> writes:
In article <optbof6t0b23k2f5 nrage>, Regan Heath says...
  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(...)
  {
  }

This is a terribly biased example against individual protection attributes, because that code is organized so poorly. Its illogical to assume that people who put a protection attributes on each field/function just randomly glop their code together like in your example. I use individual protection attributes, yet I still structure my code so the private functions are in one area and the public ones in another.
Jun 24 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Sun, 25 Jun 2006 13:07:14 +1000, Ben Phillips <Ben_member pathlink.com>  
wrote:

 In article <optbof6t0b23k2f5 nrage>, Regan Heath says...
  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(...)
  {
  }

This is a terribly biased example against individual protection attributes, because that code is organized so poorly. Its illogical to assume that people who put a protection attributes on each field/function just randomly glop their code together like in your example. I use individual protection attributes, yet I still structure my code so the private functions are in one area and the public ones in another.

Yes, I did purposely exagerate the issue. But is this really any more readable? ... private a_type var1; private a_type var8; private int func6(...) { } private a_type var3; private a_type var5; private a_type var7; private static int func3(...) { } private static a_type var6; public int func5(...) { } public int func2(...) { } public a_type var4; public static a_type var2; public static int func1(...) { } public static int func4(...) { } I know its a personal taste question, but to me it has too many 'noise' words in it that makes it harder to read and write. private { a_type var1; a_type var8; a_type var3; a_type var5; a_type var7; int func6(...) { } static { int func3(...) { } a_type var6; } } public { a_type var4; int func5(...) { } int func2(...) { } static { a_type var2; int func1(...) { } int func4(...) { } } } just seems neater and more likely to be correctly read and maintained. Anyhow, I've finished with this topic. Thanks for indulging my ravings. -- Derek Parnell Melbourne, Australia
Jun 24 2006
prev sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Boris Wang 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.

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.

Well, I tend to agree with you. But data declaration with group modifiers seems clearer to me anyway. So I think it is good to have both styles. -- AKhropov
Jun 24 2006
prev sibling next sibling parent reply Daniel Keep <daniel.keep.list gmail.com> writes:
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
Jun 23 2006
parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"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.

 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 

Jun 23 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 24 Jun 2006 07:55:54 +0800, Boris Wang <nano.kago hotmail.com>  
wrote:
 The key is that your's pleasure is the suffering of other people!

The exact same thing can be said right back at you! :) Regan
Jun 23 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Jun 23 2006
parent reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"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.

 

Jun 23 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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 hate it and prefer the : syntax :) Regan
Jun 23 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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 ;)
Jun 23 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 23 Jun 2006 21:31:14 -0400, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:
 "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 ;)

I have never needed to do that. But lets assume I need to, in that case I'll use {} :) The time I tend to use private etc inline is when there is only a single method which requires it (a single things which differs from the others inside the block), eg class A { //implicit/explicit public: ..many methods.. private int a; } if there were several I'd say: class A { //implicit/explicit public: ..many methods.. private: int a; int b; } These coding practices aren't even hard and fast rules, they've evolved over time* and I'm sure I break them some of the time. In addition if I'm working on a project with others (something I'm doing right now) I'll adapt my practices to the practices of the group, it's really no problem for me how it's written, in the end it's just more or less typing (or copy/paste). I think in general the more code you read written in different ways the better you get at discerning the true meaning from any particular piece of code and the better you become as a programmer. ('you' meaning 'people in general' not anyone specifically) I have had a lot of experience reading code from many people of different skill levels and habits, it's no longer a problem for me how it's written and as such I don't really care how you or anyone else writes their code. I tend then to write mine however I like, usually in the simplest way possible. This entire thread seems to me to be about prescribing how people should write code and I disagree with it on principle. Regan *often making me wish for a program to rearrange my old code to my new practices ;)
Jun 23 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:optbmo3ih323k2f5 nrage...

 *often making me wish for a program to rearrange my old code to my new 
 practices ;)

I know that feeling! Last fall, I suddenly found myself hating not having spaces on either side of operators and after commas. By now most of my code has been converted to the new style, but I still find a few "a=b+c" here and there :)
Jun 23 2006
prev sibling parent Frank Benoit <keinfarbton nospam.xyz> writes:
Boris Wang schrieb:
 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. 
 
 

I second that. - public statement; - public {} This is good, easy, consistent. - public: is ugly C++ style and a bad choice if you can do better. And in this case you can always use the {} form, which expands the "public" until a defined place. Removing it will perhaps break some existing code, but it will also make D another bit more easy. Please also remove the inheritance protection.
Jun 24 2006