Uniform Function Call Syntax(UFCS) and @property

[Jonathan M Davis]

On Friday 04 March 2011 18:50:59 Michel Fortin wrote:
> On 2011-03-04 13:04:59 -0500, Jim <bitcirkel at 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