Uniform Function Call Syntax(UFCS) and @property

[kenji hara]

2011/3/4 Jonathan M Davis <jmdavisProg at gmx.com>:
> 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. Modules are really only
> organizational entities, not things that you deal with directly in the code. And

I can basically agree with you. But that reason can not limit the
design of the module.
Some of D users may consider a module as a singleton. We can't prohibit it.

> if you have a "property" of a module, then it's more like treating @property
> purely as an abstraction of a variable rather than really being a property of
> something. At that point, I'd almost argue that the annotation should have been
> @variable instead.

I still have the opposite viewpoint with you. A "property" of a module
should be annotated
with @property.

> 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.

Current @property annotation does not have enforcement. When this has
been improved
in the future, the way annotating ’this' on UFCS will be also necessary.

Thanks.

Kenji