On 2013-01-29 05:16, sclytrack wrote:

> If you disallow this. You will have to invent something else than
> opDispatch.
> Something that serves them both. opPropMethodDispatch maybe.

Why not allow to overload on @property?

-- 
/Jacob Carlborg

On 2013-01-29 02:59, Craig Dillabaugh wrote:
> I find such code rather baffling. Perhaps it has valuable uses
> somewhere, which is why I am asking.
>
> It sort of reminds me of Python where you can do something like:
>
> ' '.join( list_of_strings )
>
> which is very cute and all, but the following, rather mundane
> function call would do a better job of conveying to the reader
> what is going on, using the same number of keystrokes:
>
> join( list_of_strings, ' ')


Thanks to D I no longer have problems with join in Python. :)
Looking at ' '.join(aList) I now think of UFCS and see it as:
join(' ', aList). Suddenly everything is clear. :)

Am 29.01.2013 05:16, schrieb sclytrack:
> On Tuesday, 29 January 2013 at 01:09:17 UTC, F i L wrote:
>> why in the hell would you want:
>>
>>     writeln = "lolwut";
>>
>> to compile in the first place?
> 
> If you disallow this. You will have to invent something else than opDispatch. Something that serves them both. opPropMethodDispatch maybe.


template opDispatch(string name)
{
	static if( isAProperty!name ){
		@property int opDispatch() { return 0; }
	} else {
		void opDispatch() {}
	}
}

or similar should work.

On 2013-01-29 02:59, Craig Dillabaugh wrote:

> It sort of reminds me of Python where you can do something like:
>
> ' '.join( list_of_strings )

That looks kind of backwards. I would go with:

list_of_strings.join(' ')

Which feels more natural.

-- 
/Jacob Carlborg

On Tuesday, 29 January 2013 at 10:34:59 UTC, Sönke Ludwig wrote:
> Am 29.01.2013 05:16, schrieb sclytrack:
>> On Tuesday, 29 January 2013 at 01:09:17 UTC, F i L wrote:
>>> why in the hell would you want:
>>>
>>>     writeln = "lolwut";
>>>
>>> to compile in the first place?
>> 
>> If you disallow this. You will have to invent something else than opDispatch.
>> Something that serves them both. opPropMethodDispatch maybe.
>
>
> template opDispatch(string name)
> {
> 	static if( isAProperty!name ){
> 		@property int opDispatch() { return 0; }
> 	} else {
> 		void opDispatch() {}
> 	}
> }
>
> or similar should work.

I meant for dynamic D where you don't know if it is a property or a method at compile time. Where you don't know if the method even exists or not.

Overloading on an annotation is just weird. Either something is annotated or not.

Going to eat now.

> I think the root reason why such confusion is the bad choice that D made in the beginning, to define properties with the same syntax as functions, while properties should be rather an extensions of the variable concept, not of the functions concept.

Properties should only appear to be variables from the user's point of view. From the implementation point of view, they *are* functions. So the syntax for getting and setting property values should be the same as for variables, but for implementing them, it makes sense to use syntax that is close to the one used for functions. That way, you can avoid verbosity and the need to use implicit parameters, like what they have in C#.

Current implementation of properties in D is not perfect, but the only issue with the syntax for implementing them is that there isn't a clear distinction between setters and getters, which leads to some confusion with global properties in the presence of UFCS. But that can be solved by having @property(get) and @property(set) or @getter and @setter. No need to adopt the inferior C# approach.

On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
> to the one used for functions. That way, you can avoid verbosity and the need to use implicit parameters

What do you eran from that? Sparing "value" as a reusable identifier? You define a getter at the top of the class, then finding a setter three screens lower and you finnaly learn that the property is not that "read-only"?

I think the first step into better property definition/implementation/comprehension would be exactly that: to force the code of the getter and the code of the setter to stick together.

Yes, exactly at the user of a property I was thinking. That user is also a programmer, but he does not do the implementation of the property, just using it.

The confusion does not lie with that user, but it was sparked when the implementation decision was made, in the very heads of those who started implementing properties as just-another-function.

This confusion propagates from the implementors to the user, as the (usage) syntax issues are issues for the user.

It also does not help that, for the time being, the users of properties are also the implementors of properties. There is not much objectivity in this case.

On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
> need to adopt the inferior C# approach.

And there is another problem with the "superior" D approach: a typing mistake in the name of a property might let you not with one property that is r/w, but with two properties to which one is r/o and the other is w/o.

More, those functions might be placed several screens far one from the other.

Even more, defining the properties as (regular) functions makes it very difficult to teach a programmer: "in this body of code you should restrain yourself from doing certain things", because he already feels that inside a function he shoiuld have a lot of freedom.

It would have been easier to say: "you know, property is like a variable, but you can also add there *some* instructions (ie: range checking, database interrogation, cache and so on)".

On 2013-01-29 09:03, eles wrote:
> Let me turn the table: why not thinking about the property as a variable that,
> optionally (start another UFCS/opt-parens discussion here...) accept the syntax:
>
> v(2);

It is a bit confusing because if it were methods/functions you'd typically have "getV()" and "setV(2)" which show what is being done here. "v(2)" on the other hand doesn't make it clear whether it will set the value or read it. After all "2" might be some flag/index/anything used to specify the return value and it still won't make "v(int)" a setter. In the end one would have to look into the docs to see what "v" does. This is unnecessary if you either tell in the function name what will be performed or use the property like any normal variable. Therefore when using properties I would rather just see "v" and "v = 2" (and also expect "w = v = 2" to work).

Assuming that "w" is a plain int variable, I wouldn't expect to see v(2) anywhere outside initialization, just like I would not expect to see w(2).

On Tuesday, 29 January 2013 at 11:36:22 UTC, FG wrote:
> On 2013-01-29 09:03, eles wrote:
>
> It is a bit confusing

I know. It was an alternative way of thinking, displayed just to show how weird things may become.

I also fine

writeln = "hello"

very confusing. Is that a variable assignment, btw? What do you think?