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

Daniel Keep daniel.keep.list at gmail.com
Fri Jun 23 06:56:58 PDT 2006


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



More information about the Digitalmars-d mailing list