@property - take it behind the woodshed and shoot it?

Alvaro alvaroSPAMALOTsegura at gmail.com
Tue Jan 29 05:27:17 PST 2013


I agree with Adam's view and I really think @property is a good 
thing.

APIs have to specify their semantics and clearly distinguish 
properties from functions, which may be implemented similarly but 
*mean* different things. Basically a property is a *thing* or a 
characteristic, normally a noun, whereas a property is an action, 
normally a verb.

As a special case, a property can be a delegate or function, and 
calling it with () would apply the parens to the delegate (which 
the user is explicitly calling), but not to the property.

Properties as they are can also be used to emulate "indexed 
properties", as in other languages. If a property's type is a 
struct that implements [] and []= then we can do:

image.pixels[x,y] = Rgb(255,0,0);

And yes, I think properties should always be called ["used" I 
would rather say] without parens, and functions always be called 
with parens. Isn't it like this in other languages, e.g. C#, BTW?

But anyway as I don't develop the compiler, I speak from a 
distance, and I'm not aware of the implementation complications 
there may be...



On Thursday, 24 January 2013 at 13:43:34 UTC, Adam D. Ruppe wrote:
> No, god no. This would break code AGAIN and still not fix the 
> problems, instead introducing new ones!
>
> I think any property proposal that talks about parenthesis in 
> the definition is wrong. With a good definition, the existing 
> type system will handle the parenthesis.
>
> @property int foo() { return 10; }
>
> foo(); // the correct error is "type int is not callable"
>
> This is the key point:
>
> A property is NOT a function as far as user code is concerned. 
> That's just an implementation detail.
>
> As far as user code is concerned, a property IS its return 
> value.
>
>
> If you implement that, leaving all the other rules in the 
> language exactly the same, we'll actually fix some problems 
> without breaking the overwhelming bulk of existing code.
>
>
> Fixing the rest of the problems is then about getting op*Assign 
> to work right.
>
>
>
> Functions not marked @property should NOT change AT ALL from 
> what we have now. I am against removing the existing optional 
> parenthesis rule, and I am against removing the @property 
> decoration.
>
> Fix it this time, don't break it in a different place.



More information about the Digitalmars-d mailing list