www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Uniform Function Call Syntax(UFCS) and property

reply kenji hara <k.hara.pg gmail.com> writes:
The two semantics have no relation with each other.

My idea is that we allow 'this' keyword as the first parameter of free function:
----
T t;

void method(T)(ref T this){...}
--> t.method();
void method(T, A...)(ref T this, A args){...}
--> t.method(arg1, arg2);

 property bool empty(T)(ref T this){...}
--> if (t.empty){...}
 property void empty(T)(ref T this, bool f){...}
--> t.empty = true;
----

Do you think?
Mar 03 2011
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-03-04 08:30:44 -0500, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 Note that there is only one (currently) ambiguous case, the case of a  
 getter on an array or a setter on the module.  A setter on an array 
 cannot  be confused with something else, as well as a getter for the 
 module.
 
 What we need is a syntax to disambiguate.  So essentially, we take the  
 most common case, and declare that as the default.  But if you define 
 the  property this way * then it becomes a property the other way.

Perhaps instead of property we should have had getter and setter. It's shorter to write and easier to disambiguate. It might be too late to change that however. Another idea someone proposed (I can't find the exact post to give proper credit) would be to allow having a parameter named 'this'. This would allow the creation of non-member functions using the member syntax as with the Uniform Function Call Syntax but without the "Uniform" part: only function specially labeled this way would be eligible to the member call syntax. This would solve our property problem, but is dependent on how UFCS is implemented. Disallowing global-scope properties isn't very appealing to me. I hear Jonathan's plea that the word "property" means a property *of* something, implying it should be a member, but I think it's hair splitting. D has always allowed properties at global scope, I see no reason to change that only because we used the perhaps-not-totally-appropriate word "property" to name such a concept. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 04 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 03/04/2011 06:26 PM, Michel Fortin wrote:
 Another idea someone proposed (I can't find the exact post to give proper
 credit) would be to allow having a parameter named 'this'. This would allow the
 creation of non-member functions using the member syntax as with the Uniform
 Function Call Syntax but without the "Uniform" part: only function specially
 labeled this way would be eligible to the member call syntax. This would solve
 our property problem, but is dependent on how UFCS is implemented.

Lua version (center on "add a new method"): -- hand-baked Lua OO type Point = { this = function (p, coords) point = {x=0, y=0} for k,v in pairs(coords) do point[k] = v end return setmetatable(point, Point) end , __tostring = function (point) return "Point(" .. point.x .. "," .. point.y .. ")" end , } Point.__call = Point.this Point.__index = Point setmetatable(Point, Point) -- a point point = Point {x=1, y=2} print (point) --> Point(1,2) -- add a new method Point.move = function (point, offset) point.x = point.x + offset.x point.y = point.y + offset.y end -- applicate added method (special syntax ':') point:move {x=3, y=4} print (point) --> Point(4,6) Denis -- _________________ vita es estrany spir.wikidot.com
Mar 04 2011
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-03-04 13:04:59 -0500, Jim <bitcirkel 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 michelf.com http://michelf.com/
Mar 04 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 04 March 2011 18:50:59 Michel Fortin wrote:
 On 2011-03-04 13:04:59 -0500, Jim <bitcirkel 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
Mar 04 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/05/2011 03:50 AM, Michel Fortin wrote:
 On 2011-03-04 13:04:59 -0500, Jim <bitcirkel 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
Mar 05 2011