dcollections 1.0 and 2.0a beta released

[Steven Schveighoffer]

On Mon, 24 May 2010 11:45:51 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 05/24/2010 10:01 AM, Steven Schveighoffer wrote:
>> On Fri, 21 May 2010 13:42:14 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 05/19/2010 08:42 PM, Steven Schveighoffer wrote:
>>>> Andrei Alexandrescu Wrote:
>>>>
>>>>
>>>> I.e. there aren't many kinds of HashMaps that derive from each
>>>> other. But the interfaces are not detrimental to your ideas. The
>>>> only thing interfaces require is that the entities implementing
>>>> them are classes and not structs. As long as you agree that
>>>> classes are the right call, then interfaces can co-exist with
>>>> your other suggestions without interference.
>>>
>>> This brings back a discussion I had with Walter a while ago, with
>>> echoes in the newsgroup. Basically the conclusion was as follows:
>>> if a container never escapes the addresses of its elements, it can
>>> manage its own storage. That forces, however, the container to be a
>>> struct because copying references to a class container would break
>>> that encapsulation. I called those "perfectly encapsulated
>>> containers" and I think they are good candidates for manual memory
>>> management because they tend to deal in relatively large chunks.
>>>
>>> I noticed that your collections return things by value, so they are
>>>  good candidates for perfect encapsulation.
>>
>> Then you need reference counting, I don't think that is a good
>> design.
>
> Why?
>
> I think refcounting for containers is perfect.
>
> Refcounting small objects is bad because the counter overhead is large.
> Also, small objects tend to be created and passed around a lot, so the
> time overhead is significant.
>
> In contrast, refcounting and containers are a perfect marriage. The
> container is a relatively large conglomerate of objects so refcounting
> that is bound to yield good benefits in terms of memory reclamation.

I meant refcounting elements.  If you are simply refcounting the  
container, what do you do when someone wants to remove a node?  Not allow  
it if more than one reference to the container exists?

>>
>> Java has some warts as you have rightfully pointed out in the past
>> (i.e. O(n) lookup), but I have attempted to remove all those warts.
>> Dcollections I would hope does not suffer from the problems that
>> Java's collections suffer from.
>
> That's great. But let me quote what you said: "I myself don't really use
> the interface aspect of the classes, it is mostly a carryover from the
> Java/Tango inspirations." I took that to mean you don't have a strong
> justification for structuring dcollections as a hierarchy, and
> furthermore that makes me hope it's possible you'd be willing to yank
> that dinosaur brain.

I did not have a strong justification for using interfaces originally, and  
my first interface design shows that.  But I think with careful design,  
the interfaces in the D2 version are pretty useful in some situations, all  
of which could be essential to a project's design.

In other words, I don't see the fact that Java or Tango's original  
collection package had interfaces as a "wart".

The problem I see right now is, a lot of that utility is moot since D is  
not very good at dynamic linking.  Since you necessarily have to  
statically link Phobos and dcollections, it makes no sense to keep binary  
compatibility, or hide implementation.

> Looks like we're heading straight to stalemate once again.
>
> In the interest of time, it would be better to get to stalemate (or,  
> hopefully, agreement) so we know whether dcollections will be integrated  
> within Phobos or whether I should spend this and next weeks' evenings  
> coding. To that end, please let me know whether it's worth that I spend  
> time on putting together a list of proposed changes.

I think if we can keep dcollections as classes, then the opportunity to  
have interfaces still exists for the future.  If that's the case, we can  
ditch the interfaces for now, and revisit it when D's dynamic lib support  
gets better.

So let's move on to other issues.  I haven't changed my mind on interface  
utility, but there seems to be not much support for the idea.

-Steve