[phobos] Time to get ready for the next release

[Jacob Carlborg]

On 24 apr 2011, at 01:27, Jonathan M Davis wrote:

>> On 22 apr 2011, at 00:28, Jonathan M Davis wrote:
>>> Actually, setters _should_ return void. The chaining should be done by
>>> calling both the getter and setter functions. The other options is a
>>> property function which takes nothing but returns a ref. In either case,
>>> the chaining would work.
>> 
>> Wouldn't this require some form of property rewriting?
> 
> Hmmm. Yes it would, which I was thinking was what properties were doing 
> anyway, but now that I think on it, I'm not sure they do. The getter certainly 
> doesn't, but I don't know about the setter. So, I'm not quite sure what the 
> compiler is doing right now, but calling both the getter and setter for 
> chained assignment would require a lowering.

I'm pretty sure it doesn't do any property rewriting. There's also this problem (that also C# has) that also has been discussed before:

foo.bar.value = 3;

"foo" is a struct or an object. "bar" is a getter property which returns an object and "value" is setter property that sets a value. If you have some kind validation in a "bar" setter property it will be bypassed. This can be fixed with property rewriting. BTW, I pretty sure there's an issue in bugzilla about this.

> Then again, now that I think of it, if you require both the getter and setter 
> for chained assignment, chained assignment won't work for write-only 
> properties. So, I don't know what the solution should be. It was my 
> understanding that a function could _be_ a setter if it returned anything. It 
> had to take a single value and return nothing (or take two values where the 
> first was an array and you were calling it using the array's member function 
> call syntax). And with that being the case, you _must_ use the getter to 
> generate chained assignments.

Can't that be a requirement, to have a getter, to be able to do chained assignment. How often do you actually provide only a setter without a getter?

> So, now I'm a bit confused on the chained assignment bit. The fact that the 
> compiler virtually ignores @property right now makes it much harder to 
> determine how it's supposed to work. It was my understanding that
> 
> T prop() //getter
> void prop(T val) //setter
> ref T prop() //both getter and setter
> 
> were supposed to be the only valid signatures for getters and setters (save 
> for the addition of the array parameter with arrays), and it seems like that's 
> not currently true. TDPL is very specific that the syntax is supposed to be 
> strictly enforced, but it's not very specific on the correct signatures for 
> getters and setters.

I always return the set value in a setter to allow chained assignments.

> So, after this discussion, I'm at least marginally confused. Certainly, a lot 
> of what some folks expect of properties comes from what currently works rather 
> than what's supposed to work, and what's supposed to work is not always clear 
> - at least as far as the exact signatures for getters and setters go.

Yeah, with D that seems to happen far to often. The compiler does one thing, the specification says another thing and now with the addition to TDPL we possibly have a third interpretation.

> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg