Uniform Function Call Syntax(UFCS) and @property

[Jonathan M Davis]

On Thursday, March 03, 2011 12:32:44 kenji hara wrote:
> It seems to me that you think only combination of member-variable like
> property and UFCS.
> My suggestion is consider global-variable like property as well.
> example:
>   @property int global_var(){...}  // getter, int n = global_var;
>   @property void global_var(int n){...}  // setter, global_var = 10;
> 
> I think that global variable like setter function and member-variable
> like getter function occur ambiguity.
> Getter and Setter are the opposite meaning.

I'd strongly argue that global/module properties make no sense. What are they a 
property of? The module? The whole idea with properties in the first place was to 
be an abstraction of member variables. And since you really shouldn't be using 
mutable global/module variables anyway, the benefit of such a "property" is 
already limited. And if they cause ambiguity (as they obviously do), then that's 
one more reason to disallow them.

Conceptually, I don't think that properties make any sense unless they're 
properties of a type (be it a user-defined type, or an array, or some other type 
called with UFCS). A property is a property _of_ something, not just a random 
variable. And from a practical point of view, allowing properties which aren't 
on a type causes ambiguity, so they make that much _less_ sense.

If you disallow global/module "properties," then you don't need any special 
syntax to deal with the problems that they might cause.  They should just work. 
I see no reason to allow global/module "properties" when they don't make sense 
conceptually and they cause ambiguities if you try and allow them.

- Jonathan M Davis