@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