> What do you eran from that? Sparing "value" as a reusable identifier?

Not using a magic identifier, which makes the code clearer.

> 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"?

Nothing is stopping you from keeping the getter and setter together. It also seems to me that this is something people would usually do, as you usually write one of those right before you write the other, and later inserting some other definition between them just feels wrong. How many times have you encountered this problem?

> 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.

So you are assuming that having a special syntax for defining properties has some psychological effect on programmers that results in proper usage of properties, and that the lack of such syntax in D is the main reason for improper property usage.

I disagree. I think that the main reason @property is currently overused in D  is that people were under the impression that paren-less  calls will only be supported for @property functions in the future. So if people wanted some of their functions to be callable without parens (and some people do want that), they actually had an incentive to make them @property, even if they weren't logically properties.

> 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.

A bug like this will be found as soon as someone writes a test for that property or writes some code that uses it. And once it is found, it is trivial to fix. If the code was not tested at all, it is bound to contain other bugs anyway and some of those will be much harder to find and to fix.

On 2013-01-29 13:13, eles wrote:
> I also find
>
> writeln = "hello"
>
> very confusing. Is that a variable assignment, btw? What do you think?

To me this is just a lousy party trick... pulling a rabbit out of the hat. ;)
Makes absolutely no sense, because writeln doesn't store "hello" in its state - there is no way to read it. Maybe it's a limited mindset, but to me properties should be read-only or read-write, but not write-only.

On the other hand, if it was a hypothetical property (let's call it "lastDebugMessage"), that stores and returns the string, while also printing it as a side-effect, then it could be acceptable (although this particular example is of limited practical value).

On 01/29/2013 06:26 AM, eles wrote:
> 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.

IIRC, C# goes like this:

property int foo
{
	get
	{
		return m_foo;
	}
	
	set
	{
		m_foo = value;
	}
}

C# properties have a couple disadvantages:
- They introduce an extra nesting level.
- There is a possible nonsense error if someone places code outside of the get/set but inside the property scope.
- You don't get to determine how the setter value is passed.  ref? auto ref? const?
- They use 4 keywords, whereas we can get away with 2 probably.
- Things get uglier when you add D's function pure and const annotations to it.

I think there are another disadvantage or two that Andrei mentioned before in a property discussion a couple years ago.  He fairly well convinced me that C#'s property syntax isn't the right thing for D.

Semantically, they accomplish the same thing as D's properties: they get lowered into two methods, one getter and one setter.  There has to be /some/ way to attach executable code to a symbol for this properties concept to work at all.

On 01/29/2013 07:13 AM, eles wrote:
> 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?
>

I don't think anyone likes it.

What I'm trying to accomplish with my thread is find a way to remove such corner-cases without also removing other things that people care about, like omittable parens on call-chains.

On Tuesday, 29 January 2013 at 13:52:27 UTC, Chad Joan wrote:
> On 01/29/2013 07:13 AM, eles wrote:
>> On Tuesday, 29 January 2013 at 11:36:22 UTC, FG wrote:
>>> On 2013-01-29 09:03, eles wrote:
>>>
>
> What I'm trying to accomplish with my thread is find a way to remove such corner-cases without also removing other things that people care about, like omittable parens on call-chains.

well, make those parens omittable (I think it is a molima: everybody seems to have fallen in love with that optional parens) only if the function name is followed by a dot.

This will avoid such ugly things as:

a.writeln;

except for properties (@property will enforce this syntax, even if not followed by a dot).

On 01/29/2013 06:03 AM, sclytrack wrote:
> 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 didn't think it was an overload.  I also don't understand the bit about dynamic D, because the dispatch in opDispatch always occurs at compile-time.  Any strings used as method names on a type with opDispatch must be known at compile-time.  This is reasonably expressive enough that I wonder if you're doing other dynamic calculations behind that all.

That template works, though I was also thinking about this natural use-case:

import std.stdio;

class Foo
{
	void opDispatch(string name)(int arg)
	{
		writefln("%s(%s) called",name,arg);
	}

	@property opDispatch(string name : "prop")(int arg)
	{
		writefln("prop = %s", arg);
	}
}

void main()
{
	auto f = new Foo();
	f.test(5);
	f.prop = 9;
}

// Writes:
// test(5) called
// prop = 9

This might be confusing to me because I'm not sure what your use case is.  How are you generating your opDispatch functions currently where this becomes a problem?

On Tuesday, 29 January 2013 at 12:24:18 UTC, jerro wrote:
> A bug like this will be found as soon as someone writes a test for that property or writes some code that uses it. And once it is found, it is trivial to fix. If the code was not tested at all, it is bound to contain other bugs anyway and some of those will be much harder to find and to fix.

except that someone would write the getter, then write the tests for the getter.

several years latter, another programmer writes the setter, and then the tests for the setter.

both the tests for the setter and for the getter work (and, through some hasard, even read/write tests would work, if anybody care to write).

then you put that class into production code and the plane crashes.

On Tuesday, 29 January 2013 at 12:18:56 UTC, jerro wrote:
>> What do you eran from that? Sparing "value" as a reusable identifier?
>
> Not using a magic identifier, which makes the code clearer.

Yes. What about removing $ in array context? That makes it a very magic identifier.

OK: use "$" instead of "value". It is magic already.

> Nothing is stopping you from keeping the getter and setter together.

The problem is that nobody enforces you. Nobody is stopping you from writing corect code, I can swear that. Still, bugs exist. And in your code, too.

> So you are assuming that having a special syntax for defining properties has some psychological effect on programmers that results in proper usage of properties, and that the lack of such syntax in D is the main reason for improper property usage.

I think it will make things clearer for them: a lot of debate was needed just to make clear that UFCS/optional_parens and @property are orthogonal issues. Do you think that confusion in the beginning had nothing to do with the F meaning... FUNCTION?

> I disagree. I think that the main reason @property is currently overused in D  is that people were under the impression that paren-less  calls will only be supported for @property functions in the future. So if people wanted some of their functions to be callable without parens (and some people do want that), they actually had an incentive to make them @property, even if they weren't logically properties.

You see: optional parens mean function, @property means property. The confusion that you spot is exactly the confusion that is rooted into that mix of properties and functions.

On Tuesday, 29 January 2013 at 13:51:05 UTC, Chad Joan wrote:
> On 01/29/2013 06:26 AM, eles wrote:
>> 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
> IIRC, C# goes like this:

YRC.

> property int foo
> {
> 	get
> 	{
> 		return m_foo;
> 	}
> 	
> 	set
> 	{
> 		m_foo = value;
> 	}
> }
>
> C# properties have a couple disadvantages:
> - They introduce an extra nesting level.
> - There is a possible nonsense error if someone places code outside of the get/set but inside the property scope.

The compiler will scream at you. This is why it analyses the code, to make sure it understands it.

> - You don't get to determine how the setter value is passed.  ref? auto ref? const?

Frankly? Why you would care? You only write a.x=b. How it is b passed? It is the job of the compiler to pass b, not yours.

> - They use 4 keywords, whereas we can get away with 2 probably.

Yes. This is why brainfuck become no.1 language ever invented, because it uses very few keywords. And this is why Java never really took off, just because it introduces new keywords like extends and implements instead of our lovely :. Lovo of keywords changed the world...

> - Things get uglier when you add D's function pure and const annotations to it.

*Everything* become uglier with that. Everything.

> Semantically, they accomplish the same thing as D's properties: they get lowered into two methods, one getter and one setter.  There has to be /some/ way to attach executable code to a symbol for this properties concept to work at all.

If they are the same, why they are different to the point that you love one but hate the other?