[phobos] Time to get ready for the next release
Jacob Carlborg
doob at me.com
Sun Apr 24 04:29:22 PDT 2011
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
More information about the phobos
mailing list