ref returns and properties

Sean Kelly sean at invisibleduck.org
Mon Jan 26 08:41:20 PST 2009


Don wrote:
> Andrei Alexandrescu wrote:
>> Jacob Carlborg wrote:
>> [on properties]
>>> What about this:
>>>
>>> class Host
>>> {
>>>      property acquire release prop
>>>      {
>>>          T get();
>>>      }
>>> }
>>>
>>> And then the compiler will automatically created the "acquire" and 
>>> "release" methods.
>>>
>>> There could also be what I would like to call "property shortcuts" 
>>> (ruby calls this attributes) like this:
>>>
>>> class Host
>>> {
>>>      get acquire release T prop;
>>>      get set T prop2;
>>> }
>>
>> I was hoping I'd shield putative users from having to write verbose 
>> code. Besides, there's one other issue I stumbled upon while working 
>> on porting std.algorithm to ranges.
>>
>> You can't really pass an entire property to a function. This furthers 
>> the rift between properties and true fields. Consider:
>>
>> struct A { int x; }
>> void foo(ref int n) { if (n == 0) n = 1; }
>> ...
>> A obj;
>> foo(obj.x);
>>
>> So when passing obj.x to foo, foo can read and write it no problem. 
>> But if x is a property of A, it all falls apart: obj.x means just 
>> reading the property, not getting the property with all of its get and 
>> set splendor.
> 
> I'm starting to wonder if we need some restrictions on fields, in order 
> to make properties and fields interchangable.
> The idea that a field could eventually be completely replaceable with 
> functions is appealing, but I think it's only possible with a huge 
> performance hit. One can distinguish between POD fields (for which any 
> operation is legal) and property fields (which you cannot take the 
> address of, for example).
> Arguably classes should normally not contain public POD fields, only 
> public property fields. Perhaps this is a useful concept.

I'm hesitant to assert that it should be illegal to take the address of 
a public data member, but this is certainly an intriguing idea.  The 
only other option I can think of would be to make swap a built-in 
property of concrete types and expecting the user to call a.swap(b), 
though it seems weird that a.swap(b) couldn't be rewritten as swap(a,b) 
for any concrete type, regardless of context.


Sean



More information about the Digitalmars-d mailing list