On Mon, 24 May 2010 11:45:51 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 05/24/2010 10:01 AM, Steven Schveighoffer wrote:
On Fri, 21 May 2010 13:42:14 -0400, Andrei Alexandrescu
<[email protected]> 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
