Uniform Function Call Syntax(UFCS) and @property
Steven Schveighoffer
schveiguy at yahoo.com
Fri Mar 4 05:30:44 PST 2011
On Thu, 03 Mar 2011 18:03:48 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
wrote:
> On Thursday, March 03, 2011 14:07:30 Steven Schveighoffer wrote:
>> On Thu, 03 Mar 2011 16:56:45 -0500, Jonathan M Davis
>> <jmdavisProg at gmx.com>
>>
>> wrote:
>> > Conceptually, a property makes no sense unless it's a property _of_
>> > something.
>>
>> This is your opinion, not fact. It is a property of the program/global
>> namespace/module whatever you want to call it.
>
> Per the definition of the word property, a property must be property _of_
> something. Anything else would violate the definition of the word (not
> that
> programming has ever held itself all that firmly to English
> definitions). You can
> certainly argue that a global property is a property of a module, at
> which point
> it _does_ make sense in the sense that it is then a property _of_ the
> module.
> However, I definitely think that that's pushing it.
I was debating this assumption you have made in making your statement, not
the statement itself. Sorry, I sometimes don't express myself very well.
I'll try again:
It is your opinion that modules or classes/structs do not qualify as
entities to define properties on. Not a fact.
I disagree completely, and have given several counter-cases. What do you
say about the examples, such as the Singleton, or the cache variable I use
in druntime?
> Regardless, I'd still argue that @property shouldn't be allowed at the
> module
> level as long as it's going to create ambiguities. And adding extra
> rules or
> syntax to make it unambiguous as Kenji is suggesting seems like overkill.
I don't disagree that making syntax might be overkill. But making rules
that are not consistent doesn't make sense either. If I have a place I
can put a variable, I should be also able to put a property there.
Note that there is only one (currently) ambiguous case, the case of a
getter on an array or a setter on the module. A setter on an array cannot
be confused with something else, as well as a getter for the module.
What we need is a syntax to disambiguate. So essentially, we take the
most common case, and declare that as the default. But if you define the
property this way * then it becomes a property the other way.
Also, keep in mind that I think UFCS should be restricted to builtins only
(i.e. primitives + arrays, not AA's, since they map to a struct that can
be customized in druntime). To provide multiple ways for one to add
members to classes/structs causes huge ambiguity/hijacking issues.
Just thought of this, I think this might be good enough:
@property(out) denotes a getter on its single argument for functions that
are at the module level and have one argument:
* if the property is inside a class or struct, then properties with no
args are always getters, properties with a single arg are always setters.
* if the property is outside a class or struct, and it has no arguments,
it's a module getter
* if the property is outside a class or struct, and it has one argument,
it's a module setter (use @property(out) to change it to a getter on the
first argument)
* if the property is outside a class or struct, and it has two arguments,
it's a setter on the first argument, as long as that first argument
supports UFCS.
We could define @property(in) also, and allow the syntax everywhere, but I
think nobody will ever use it in unambiguous cases.
Other possibilities could be used inside the parens.
-Steve
More information about the Digitalmars-d
mailing list