[OT] Finding longest documents

[Benji Smith]

Andrei Alexandrescu wrote:
> I don't want to seem like picking on you, but I would like to answer
> this message too.

I don't feel like you're picking on me! Without disagreements, there 
wouldn't be much to discuss :)

Though I do think you should lay off with the "beginner" business. The 
people who disagree with you disagree for legitimate reasons, not 
because they're inexperienced. Perhaps Josh Bloch is a beginner?

> In my humble opinion, collections APIs are the poster-child of the
> misguided joy of the beginnings of object-orientation, right next to the
> mammal isa animal example. Organizing collections in hierarchies is of
> occasional benefit, but the real benefit comes from decoupling
> containers from algorithms via iterators, the way the STL did. The
> savings there were that an O(m * n) problem has been solved with writing
> O(m + n) code. Container hierarchies do not achieve such a reduction
> unless efforts are being made that have little to do with hierarchical
> organization. At most they factor out some code in the upper classes,
> but hierarchies help when types have many commonalities and few
> difference, and that is very rarely the case with containers.

Nonsense.

Iterators are not the only way to "decouple containers from algorithms". 
An iterator in STL is just a compile-time interface for accessing the 
elements in a container.

You can argue that using type hierarchies or interface inheritance is an 
undue runtime burden and that iterators solve that problem effectively. 
But, from a data-modeling perspective, there is absolutely no difference 
between these two:

    sort(List<T> list);

    sort(iterator<T> start, iterator<T> end);

>> Structs can't inherit from abstract classes. A good deal of 
>> functionality in a collection class can be implemented once in an 
>> abstract base class, making it simpler for subclass authors to 
>> implement the API without duplicating a bunch of boilerplate.
> 
> This also reveals a beginner's view of inheritance. You don't inherit to
> reuse. You inherit to be reused. If all you want is to reuse, use
> composition.

When the rubber hits the road, I'll take my "beginners view of 
inheritance any time".

One of my favorite tiny classes in Java is this little nugget:

    import java.util.LinkedHashMap;
    import java.util.Map;

    public class CacheMap<K, V> extends LinkedHashMap<K, V> {
       int maxCapacity;
       public CacheMap(int maxCapacity) {
          this.maxCapacity = maxCapacity;
       }
       protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
          return size() > maxCapacity;
       }
    }

Now I have a fully-functional Map class that automatically removes 
entries (in FIFO order) when the collection reaches some maximum size. 
In every other way, it performs exactly like any other LinkedHashMap 
(which always iterates in insertion-order).

If I used composition, and if I wanted to comply with with Map 
interface, I'd have to manually re-implement every single method, 
wrapping the underlying functionality and delegating the calls myself. 
If the type system can do it for me, why not?

And since I've implemented Map<K, V>, I can pass my container to any 
method that cares about "mappiness", regardless of whether it cares 
about "cachiness".

>> Conceptually -- and there's no hard and fast rule about this -- 
>> structs usually either represent small logically-atomic values 
>> (DateTime), or some fixed-size collection of logically-atomic values 
>> (Vector3). Using a struct as an arbitrarily-sized container seems, on 
>> the face of it, to break those conventions.
> 
> I see how it breaks those conventions, but I've never heard of them. The
> convention I heard of is that if you want dynamic polymorphism you use
> classes, otherwise you don't.

The D documentation implies otherwise:

http://www.digitalmars.com/d/2.0/struct.html

Though I suppose you're free to use whatever conventions you like.

--benji