read-only access

Jonathan M Davis jmdavisProg at gmx.com
Tue Nov 2 16:32:53 PDT 2010


On Tuesday, November 02, 2010 14:14:22 spir wrote:
> On Tue, 2 Nov 2010 12:47:21 -0700
> 
> Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > If they don't have the property attribute, then they won't work without
> > parens (and in fact, you won't be able to use parens with them). That is
> > how it's outlined in TPDL (The D Programming Language by Andrei
> > Alexandrescu). However, dmd has not reached that point. It will still
> > allow property functions to be used with parens and non-property
> > functions to be used as property functions as long as they're void and
> > take one parameter or return a value and take no parameters. So, once
> > dmd is up-to-date with regards to TDPL, you'll no longer be able to use
> > arbitrary functions as properties, but for the moment, you can.
> 
> 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).

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.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list