On Friday 04 March 2011 18:50:59 Michel Fortin wrote: > On 2011-03-04 13:04:59 -0500, Jim <bitcir...@yahoo.com> said: > > Jonathan M Davis Wrote: > >> On Friday 04 March 2011 04:59:14 David Nadlinger wrote: > >>> On 3/3/11 10:27 PM, Jonathan M Davis wrote: > >>>> I'd strongly argue that global/module properties make no sense. What > >>>> are they a property of? The module? > >>> > >>> You could as well say: I'd strongly argue that global/module variables > >>> make no sense. What are they a variable of? The module? > >>> > >>> In my opinion, allowing global variables but not global properties just > >>> creates yet another unneeded special case. > >> > >> I see no special case or inconsistency. The original idea behind a > >> property (as I understand it) is to abstract member variables so that > >> you can easily switch between having a public member variable and > >> having a public member function without having to change code. The term > >> property implies that it is a property or attribute of whatever it's > >> on. A global variable or a local variable or any kind of variable not > >> on a class or struct is free-floating and not a property or > >> attribute of anything. How many languages which have properties have > >> them on _anything_ other than objects? > >> > >> I was surprised that anyone would suggest that @property could be used > >> on anything other than a class or struct's member function. I strongly > >> suspect that > >> the main reason that anyone is thinking that way is because properties > >> in D grew > >> out of being able to call pretty much any old function without parens > >> as long as > >> it had no parameters instead of based on the concept of properties to > >> begin with > >> as it likely would have been in other languages. > >> > >> - Jonathan M Davis > > > > Let's talk about accessors instead of properties because we are talking > > about the functions, right, not the storage per se? > > @getter, @setter as proposed by Michel Fortin. > > Actually, there's a big drawback in having separate @getter and @setter > attributes: grouping functions under one attribute declaration like > this becomes impractical: > > @property { > int length(); > void length(int); > > int capacity(); > void capacity(int); > }
Personally, I don't find that to be any great loss. I've never liked the ability to apply attributes to functions in bulk like that. The only attributes that I ever do that sort of thing with are private, protected, package, and public. And those I use : for. Regardless, the other problem is functions like @property auto ref front() {...} They're both the getter and the setter thanks to the ref. So, unless it was legal to mark such functions with both @getter and @setter, you'd need an attribute for marking functions which were both. - Jonathan M Davis