2011/3/4 Jonathan M Davis <jmdavisp...@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 <jmdavisp...@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
