new DIP5: Properties 2

[Ary Borenszweig]

Bill Baxter wrote:
> On Tue, Jul 28, 2009 at 6:54 AM, Andrei
> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>> Well there are quite a few other things that are arguably against C look and
>> feel, such as the scope statement. I've never had a problem understanding
>> code because of lacking "()", and I never ever write them.
> 
> That may be true, but you are also not an average user by any means.
> So surveying yourself may not give so accurate a reflection of
> opinions at large.
> Like Joel Spoelsky and others say about GUIs -- never take your own
> opinion that a GUI you have written is "intuitive".  You need to do at
> a minimum a couple of random "hallway checks" -- that is, getting
> random people passing by in the hallway to try it out without
> explaining it to them.  So far I think we have two people -- you and
> Walter -- who think that the current system is good.
> 
> I think you're right that people *can* get used to losing the visual
> distinction between functions and fields.  But I find the distinction
> to be a useful and unobtrusive indication of the programmer's intent.
> So I don't see losing the distinction to be worth saving a few
> keystrokes.   If there were a distinction then we could be pretty sure
> that .empty was a property and .empty() was an action.   Sure I can
> get used to having to learn which is which on a per-library basis, but
> I don't see why I should consider having to keep more stuff in my head
> to be a net win.  In fact I'm kind of envious of those languages where
> ? and ! can by used in identifiers to indicate predicates and
> mutators.
> 
> For the same reason I started to dislike like the direction some of
> these syntax proposals were taking.  Too much for me to keep in my
> head.  But the "property { ... }" syntax is very easy to remember and
> doesn't look ugly.
> 
> Look, if we add a generic attributes syntax (like @attr) we could
> perhaps use it for many of the following:
> abstract
> deprecated
> align
> case
> debug
> default
> export
> extern
> final
> lazy
> override
> package
> private
> protected
> public
> scope
> shared
> unittest
> volitile
> 
> Storage classes are, in particular, kinds of attributes of a type.
> Now we may not want to go so hog wild putting @this and @that
> everywhere, but if we did we could get rid of 19 keywords right there,
> and add @property also without adding a new keyword.

Definitely. I think attributes/annotations is the best solution for 
this. It's also the most extensible way to do it. The lexer and parser 
doesn't need to change for each new attribute. Maybe just the semantic pass.