read-only access

[Steven Schveighoffer]

On Wed, 03 Nov 2010 06:02:28 -0400, spir <denis.spir at gmail.com> 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.

The idea is that a property acts like a field, but is really a function  
under the hood.  There are no parameters for property getters.

> * 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 is quite well solved by inlining.  You should not notice any  
significant reduction in performance.

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

This is really a bikeshed discussion.  The syntax for declaring properties  
was discussed at length, and @property was chosen.  It's too late to  
change it now.  Note you can use @property to describe multiple functions  
at once via:

@property:

or

@property
{
    ...
}


-Steve