Properties

[Nick Sabalausky]

"Miles" <_______ at _______.____> wrote in message 
news:gk6f9p$1jve$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> 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.
>
> In this case, simplifying would be more complex.
>
> Under the hood, when you define getters and setters, you are defining
> functions, and function overloading is an inherent feature of the
> language. In fact, the current "property" feature of D already supports
> many overloaded setters for different types, since they are just normal
> functions.
>
> For example, consider the property definition:
>
> public property int width {
>   get() { return width; }
>   set(int value) { width = value; }
>   set(float value) { width = value + 0.5; }
> }
>
> That would generate overloaded functions with different signatures, lets
> say that, under the hood, the compiler generates:
>
> int __get_width();
> int __set_width(int value);
> int __set_width(float value);
>
> Then, when code that accesses the property is compiled, something that
> looks like
>
> width = x;
>
> will, in fact, be threated as
>
> __set_width(x);
>
> and so, the compiler will choose the appropriate __set_width() function
> with the signature that matches the above call.
>
> So, restricting a property to have only a single setter will end up
> creating unnecessary restrictions for something that is already native
> to the language.
>
>> 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.
>
> They could, no problem.
>
>> 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...
>
> It is not just about type conversions... it is that the feature is
> already something natural for the language.
>


Ok, you've convinced me on this.


>> 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
>> }
>
> Not for getters, please... the type of the getter should be the type of
> the property, or that would create a lot of complexity for the language
> (that is also the reason you don't overload functions based on the
> return type).

Well, like I said, *If* we were to get overload-on-return-value. Not that 
I'm itching for it or anything. I've just seen the idea discussed before and 
if it hypothetically were to happen, then the above could work as a getter 
equivilent.