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