Uniform Function Call Syntax(UFCS) and @property

[spir]

On 03/05/2011 03:50 AM, 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);
> }

This let me think at the actual functionality provided by the so-called 
property feature. The following is more or less thinking out loud:

* An implicite getter allows
     1. calling a method & running computations while letting think it's just 
data member access. I find this bad. The good point is a change in 
implementation, from data to method member, won't break code, *if and only if* 
the new feature does not require any param (!). Even then, silently adding a 
method call & possibly costly computation is imo bad.
     2. Implementing a setter for 4.

* An implicite setter allows:
     3. Implementing a getter for 1.
     4. Performing effects which are a logical consequence of the data member 
change. Eg "p.x = 1;" would actually /move/ p. I find this bad: there should be 
a move method, and a read-only x data member.

* A getter without setter allows:
    5. Read-only data members (to the price of language complication & a method 
call).

Finally, I think what we actually need is a read-only qualifier for data 
members. (E basta!)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com