read-only access

[Jonathan M Davis]

On Wednesday, November 03, 2010 03:02:28 spir wrote:
> Right. I know properties from python. This is also very close to the
> "principle of uniform access" supported by Bertrand Meyer for Eiffel. The
> latter means, from the client side, a "query" like obj.prop should not
> expose whether prop is directly accessed or computed and returned. This
> has the advantages you note above. But, in addition to the drawbacks you
> also note, there are 2 other relevant ones that make this scheme, indeed
> attractive at first sight, rather limited and risky in practice: * The
> advantage of beeing able to change direct access by computation only works
> when the comutation reqires no parameter! One obviously cannot opaquely
> change obj.prop to a call like obj.getProp(param)... So that using
> properties is only useful in practice when (1) the query was first direct
> (2) this needs to be replaced by computaton (3) this computation requires
> no parameter. Else, one would have to force the client to set parameters
> somewhere on the interface, before using the property; thus re-exposing
> the implementation. * From the efficiency pov, a client cannot know
> whether a given property is computed or not; worse, because of using
> ordinary direct access syntax it looks like cheap; moreover, the
> programmer may simply not know it is a property instead of an ordinary
> slot! This leads to blind overuse of property access, possibly severely
> affecting efficieny. In particular, client code may simply neglect to
> locally cache a property value and "read" it multiple times instead.
> 
> This abstraction is simply wrong in my sense, both from generality and
> efficiency points of view. ...

The programmer does have some responsibility to avoid overly-expensive property 
functions, and properties definitely can become a problem if not used 
responsibly, but there are plenty of other features that can be abused, and 
properties is one which can be avoided if you don't want to use them, though D 
convention favors using properties over explicit getters and setters.

> It also introduces synactic noise, and trouble for newcomers to the
> language. Python was forced to invent the @xyz format for its decorators
> (of which @property is an example), because of its overall syntactic
> esign. But D does not need that: it already has a whole set of modifiers
> or qualifiers well integrated in the language's syntax: private, static,
> override, etc. All of these key terms express the fact that a given
> language element (variable, function, class...) has alternate semantics
> and must be processed differently by D. Why make a syntactic exception for
> property? (I mean, if ever advantage/drawback ratio proved we simply
> cannot live without the feature.)

Java and C# have a syntax similar to D, only it's way more powerful for them, 
because you can have user-defined attributes. It allows for a lot of cool stuff 
that D can't currently do (though some of the nicer benefits may require runtime 
reflection whereas D only has builtin compile-time reflection). If anything, I'd 
like to see D go the Java and C# route on this. It can be extremely useful. 
However, in the short term, I believe that the main reason for using @ was to 
save on keywords, since Walter and Andrei don't seem to like having lots of 
keywords in the language if they can avoid it.

- Jonathan M Davis