(2011/01/29 3:31), Andrei Alexandrescu wrote:
Today after work I plan to start making one pass through std.container.
After having thought of things for a long time, my conclusions are as
follows:
1. Containers will be classes.
2. Most of the methods in existing containers will be final. It's up to
the container to make a method final or not.
3. Containers and their ranges decide whether they give away references
to their objects. Sealing is a great idea but it makes everybody's life
too complicated. I'll defer sealing to future improvements in the
language and/or the reflection subsystem.
4. Containers will assume that objects are cheap to copy so they won't
worry about moving primitives.
Any showstoppers, please share.
Andrei
>1, 2
I think that it is a good policy.
There is hardly the superiority that a containers are structs. :-)
In the first place I had doubt towards treating structs as classes
(OOP). When I use it by such a way, the lack of the default constructor
is fatal.
>3, 4
If speed is accompanied, the sealing up is useful, but if it is late,
there are many unnecessary cases. Because it is thought that a lot of
repetition access to the element and life cycles occurs in the case of a
container, handling it by the element unit should be high-performance.
In addition, for usability, a thing of simple behavior is preferable
rather than a complicated thing.
However, on the other hand, the design that wrong use is impossible
should be considered enough.
