On Thu, 03 Mar 2011 18:03:48 -0500, Jonathan M Davis <[email protected]>
wrote:
On Thursday, March 03, 2011 14:07:30 Steven Schveighoffer wrote:
On Thu, 03 Mar 2011 16:56:45 -0500, Jonathan M Davis
<[email protected]>
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
