Uniform Function Call Syntax(UFCS) and @property

Michel Fortin michel.fortin at michelf.com
Fri Mar 4 18:50:59 PST 2011


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);
	}


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list