On 2/27/15 10:34 AM, David Gileadi wrote:
> On 2/27/15 6:36 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>"
> wrote:
>> On Friday, 27 February 2015 at 08:26:14 UTC, Ola Fosheim Grøstad wrote:
>>> On Thursday, 26 February 2015 at 22:04:09 UTC, Andrei Alexandrescu
>>> wrote:
>>>> On 2/26/15 2:03 PM, Brian Schott wrote:
>>>>>
>>>>> One of the first things that stood out to me is that "add ref" is two
>>>>> words and "release" is one. For the sake of symmetry, how about these:
>>>>> *  opIncRef, opDecRef
>>>>> *  opAcquire, opRelease
>>>>
>>>> All - please PLEASE do not derail this into yet another debate about
>>>> which names are best. -- Andrei
>>>
>>> Using protocols rather than enforcing a particular implementation is
>>> nice, but D needs to stop reinventing terminology and syntax matters.
>>>
>>> -- snip --
>>
>> AddRef/Release is established COM terminology.
>
> One reason for keeping COM terminology might be if
> std.c.windows.com.IUnknown can automatically take advantage of DIP74. Of
> course this could also be a downside—would DIP74 break existing COM code
> in D?

I explicitly avoided the COM names in order to avoid potential confusion and code breakage. People can easily add IUnknownAuto that does the forwarding. -- Andrei

On 2015-02-27 19:38, Andrei Alexandrescu wrote:

> I explicitly avoided the COM names in order to avoid potential confusion
> and code breakage. People can easily add IUnknownAuto that does the
> forwarding. -- Andrei

It's still a breaking change. See one of my other replies [1] for a possible solution.

[1] http://forum.dlang.org/post/mcp5nu$1nus$1@digitalmars.com

-- 
/Jacob Carlborg

On 2/27/15 11:58 AM, Jacob Carlborg wrote:
> On 2015-02-27 19:38, Andrei Alexandrescu wrote:
>
>> I explicitly avoided the COM names in order to avoid potential confusion
>> and code breakage. People can easily add IUnknownAuto that does the
>> forwarding. -- Andrei
>
> It's still a breaking change. See one of my other replies [1] for a
> possible solution.
>
> [1] http://forum.dlang.org/post/mcp5nu$1nus$1@digitalmars.com

I'm fine with breaking code of people who happen to use the names opAddRef and opRelease. -- Andrei

On Friday, 27 February 2015 at 20:04:27 UTC, Andrei Alexandrescu wrote:
> On 2/27/15 11:58 AM, Jacob Carlborg wrote:
>> On 2015-02-27 19:38, Andrei Alexandrescu wrote:
>>
>>> I explicitly avoided the COM names in order to avoid potential confusion
>>> and code breakage. People can easily add IUnknownAuto that does the
>>> forwarding. -- Andrei
>>
>> It's still a breaking change. See one of my other replies [1] for a
>> possible solution.
>>
>> [1] http://forum.dlang.org/post/mcp5nu$1nus$1@digitalmars.com
>
> I'm fine with breaking code of people who happen to use the names opAddRef and opRelease. -- Andrei

Are op* considered reserved member names?

When a function makes/destroys multiple references to an object it should always be safe to coalesce all AddRefs into the first AddRef and all Releases to into the last Release call.

This could be a small performance win, but opAddRef/opRelease would need the count as argument or maybe as template parameter.

On 2/27/15 12:13 PM, weaselcat wrote:
> On Friday, 27 February 2015 at 20:04:27 UTC, Andrei Alexandrescu wrote:
>> On 2/27/15 11:58 AM, Jacob Carlborg wrote:
>>> On 2015-02-27 19:38, Andrei Alexandrescu wrote:
>>>
>>>> I explicitly avoided the COM names in order to avoid potential
>>>> confusion
>>>> and code breakage. People can easily add IUnknownAuto that does the
>>>> forwarding. -- Andrei
>>>
>>> It's still a breaking change. See one of my other replies [1] for a
>>> possible solution.
>>>
>>> [1] http://forum.dlang.org/post/mcp5nu$1nus$1@digitalmars.com
>>
>> I'm fine with breaking code of people who happen to use the names
>> opAddRef and opRelease. -- Andrei
>
> Are op* considered reserved member names?

No. -- Andrei

Yup, it sound like the destruction should be delegated to the destructor.

Maybe the release method could return the refcount ?

On Friday, 27 February 2015 at 07:44:18 UTC, anonymous wrote:
> We all pray you become less of a gaping asshole before youre in
> charge of anything.

Thank you for the compliment :)

Andrei Alexandrescu wrote:

> On 2/27/15 1:09 AM, ted wrote:
>> Andrei Alexandrescu wrote:
>>
>>> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss.
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>> Trivial typos:
>>
>> struct, class, and closure types that have RCO members accommodate calls
>> to Release during their destruction.
>> s/Release/opRelease/
>>
>> Explicit casting to of from void* does not entail a call to opAddRef. s/of/or/
>>
>> also: s/opReleasecalls/opRelease calls/
>>
>> The examples in "Defining a reference counted object with deallocation", and "defining a type that owns resources" both define '_refs', and manipulate 'refs'.
> 
> Fixed, thanks!
> 
>> This is probably a really stupid question, but how does the 'new' work
>> for an RCO. I assume it uses the GC memory allocation system, but must
>> mark it as 'not for collection' (or similar), for the GC.free() call to
>> work (as used in the examples).
> 
> DIP74 does not prescribe specific allocation techniques. They are left to the user.

I'm still a bit confused here: the examples in DIP74 showed the freeing of memory via 'GC.free(cast(void*) this);' - so I had assumed that 'Widget a = new Widget' would be the way it was created? (and that automatically uses GC - or is this what I am missing?)

I can see how a system that used (for example) malloc/calloc/free would work, I'm just querying the consistency of the examples within DIP74?

> 
> One nice point of the design space would be to use the GC for allocation and early deallocation, in such a way that the GC is still able to collect cycles.
> 
>> Probably another silly question: How would the examples work with
>> const/immutable (using examples in howtos)?
>> e.g. const Widget a = new Widget;
>>       auto b = a;	<-- mutable method Widget.opAddRef is not callable
>> using a const object
> 
> This is tricky. I meant to discuss it; for now I planted a TODO.
> 
> 
> Andrei

On Friday, 27 February 2015 at 22:03:06 UTC, ted wrote:
> I can see how a system that used (for example) malloc/calloc/free would
> work, I'm just querying the consistency of the examples within DIP74?
>

That is on of the 2 main problems with this DIP. The memory management of the object is linked to its memory management, which will force a ton a code duplication.

The second problem is that we are coming up with a myriad of ad hoc solutions for various aspect of the same problem, with no visibility on what the whole thing is going to look like (so there is no base to compare the current road we are taking to any alternative proposal, deemed too complex).