ref returns and properties

Denis Koroskin 2korden at gmail.com
Sun Jan 25 14:50:46 PST 2009


On Mon, 26 Jan 2009 00:59:32 +0300, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> Jarrett Billingsley wrote:
>> On Sun, Jan 25, 2009 at 3:00 PM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> But these are too many. These should suffice:
>>>
>>> class Host
>>> {
>>>     property prop
>>>     {
>>>         T get();
>>>         void acquire(ref T value) { ... }
>>>         void release(ref T value) { ... }
>>>     }
>>> }
>>>
>>> set() can be implemented as acquire from a copy, and swap can be  
>>> implemented
>>> by calls to acquire and release. Technically, get() could be also
>>> implemented with acquire and release, but that's too intensive for most
>>> types.
>>>
>>> The problem I'm seeing is that most people won't want to go through the
>>> trouble of implementing three functions for one property.
>>  I absolutely wouldn't.  Once we start doing stuff like that, we start
>> getting into tedious C++ territory.  Holding the compiler's hand,
>> writing mountains of tedious, easy-to-mess-up boilerplate code, just
>> to be able to implement simple things so they fit in with the
>> language's weird semantics.  At that point I'd _rather_ use the
>> current "properties."
>
> But you lose correctness and efficiency. I agree that in certain cases  
> they aren't paramount, but you can't build a language to not allow them.
>
> A possible solution would be to require only get, make acquire necessary  
> only for writable properties, and make release entirely optional.
>
>
> Andrei


get/set/free?



More information about the Digitalmars-d mailing list