@property - take it behind the woodshed and shoot it?
Jonathan M Davis
jmdavisProg at gmx.com
Fri Jan 25 11:30:14 PST 2013
On Friday, January 25, 2013 19:51:53 mist wrote:
> On Friday, 25 January 2013 at 18:41:46 UTC, H. S. Teoh wrote:
> > ...
>
> Sound base that avoid discussion of controversial topics :) Looks
> like I can agree with almost everything. Probably even everything.
>
> Only thing that needs to be defined is @property on
> free-functions: disallow, treat as global variable or treat as an
> extension methods. We has small discussion on this topic with
> deadalanix afair somewhere up the topic.
So, you're arguing that @property shouldn't be usable on anything but member
functions? We've had discussions on that in the past, and most everyone agreed
that it should be legal to use @property on module-level variables, and I've
never heard anyone try to argue before that it shouldn't work with UFCS (which
is what I assume you mean by extension methods - I don't know what else you
would mean). There's an ambiguity problem that needs to be solved with free
functions where in some cases, you can't properly distinguish between whether
it's supposed to be a getter or a setter, but that can be fixed (e.g.
@property(get) and @property(set)), but I think that if you're going to argue
that something like
bool exists(string filename) {...}
if(filename.exists)
or
S globalVar() {...}
if(globalVar == blah)
shouldn't work, then you're fighting a losing battle. An both of those idioms
are used in Phobos. I agree that calling it a property is a little silly when
it's a module-level variable, since there's no object for it to be a property
of, but really, @property is an abstraction for variables in general, not just
member variables.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list