read-only access

[spir]

On Tue, 2 Nov 2010 16:32:53 -0700
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Tuesday, November 02, 2010 14:14:22 spir wrote:
> > I'm not sure I like it, that properties have distinct syntax -- unless
> > there's really distinct meaning/semantics I don't know yet.
> 
> The idea is that a property is like a public member variable except that it's a 
> function underneath the hood. So, you can write code as if it were a public 
> member variable and yet it's value could be calculated instead of actually 
> having a corresponding variable in the object, or it could have extra code 
> verifying that the value you're setting it to is valid. A definite benefit of it 
> is that you can have a public member variable and then later make it a property 
> (because it becomes a calculated value, or you need extra code checking it's 
> value, or whatever) without having to change all of the code where it's used. 
> The abstraction is somewhat leaking because you can't take the address of a 
> property function in the same way you can with a public member variable, and 
> thing like += don't work because it's two different function calls instead of 
> acting directly on the variable, but it can be quite useful. Other languages 
> such as C# and Delphi have the same feature (though they have different syntax 
> for indicating when a function is a property).

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

> It makes sense for the programmer to want to indicate when a function (generally 
> when it represents a getter or setter) rather than have _all_ functions with a 
> certain signature becoming properties automatically (which is what has happened 
> in D historically). Otherwise, functions which don't really represent properties 
> are used as if they did, and there's no consistency (except perhaps by 
> convention) as to whether parens are used when calling functions which could be 
> property functions. @property  was the syntax chosen to indicate that a function 
> is intended to be used as a property. It's just that dmd doesn't entirely match 
> TDPL yet (TDPL only having come out a few months ago and Walter having been busy 
> on stuff like 64-bit support), so functions can still be called as if they were 
> properties even though they're not.

...
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.)
 
> - Jonathan M Davis

Sorry for the extensive answer (it's a topic I have explored in the past).

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com