On Wed, 03 Nov 2010 06:02:28 -0400, spir <[email protected]> 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
