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