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
