Properties

[Nick Sabalausky]

"Miles" <_______ at _______.____> wrote in message 
news:gk67hr$17d9$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> A property setter is ALWAYS going to return nothing and
>
> Both the getter and the setter should return an rvalue. Properties exist
> so that they are interchangeable with real member variables. Something
> that is possible with member variables MUST also be possible with
> properties, in a transparent way for any code outside the class.
>
> For example:
>
> button.width = button.height = 50; // makes a square button
>
> Optimally, this should expand to either:
>
> button._set_width(button._set_height(50));
>
> or
>
> button._set_height(50);
> button._set_width(button._get_height());
>
> From the compiler point-of-view, the first is easier to implement.
>

True, but my main point was, however the language ends up handling the 
details of property getters/setters, it's not going to be as general as 
ordinary functions, and thus certain aspects of the syntax can/should be 
simplified.

But regarding your examples up there, the first form might be easier for the 
compiler to implement, but I think the second would be overall better. 
You're absolutely right that properties need to be able to return an rvalue 
from an assignment, but I see no reason why that can't or shouldn't be 
transparent to the person writing the property.

>> take in exactly one argument, of the same type as the property,
>> and that value will ALWAYS represent the intended new value.
>
> Also not true. It is fine to have method polymorphism for the setter.
> You may want to define property set(int value), set(Bigint value) and
> set(float value), all with different semantics.

I'm still not 100% convinced that we should be using properties to do type 
conversions, although I suppose it may have some legitimate uses...

I guess I'm just afraid of ending up with a situation where people start 
feeling compelled to make all of their properties explicitly compatible with 
every type under the sun. All of a sudden we'd be heading towards all-out 
dynamic typing, and start losing the benefits of static typing, and, 
and...then the sun explodes...or something...(I should stay off that 
slippery slope...)

But anyway, even with the possibility of a property handling multiple types, 
I still don't think it means we can't or shouldn't have a nicely trimmed 
syntax for the more typical cases:

property int x
{
    set { this = this.new; }
    get { return this; }

    set char[] { this = StringToInt(this.new); }
    get char[] { return IntToString(this); } // If we ever got 
overload-on-return-value
}