Collections Arent Oo

Part of the motivation for this page came from CollectionOrientedProgramming, where someone challenged: There is discussion about this e.g. in StronglyTypedCollection, but I wanted to put a summary under this more obvious page title, when I noticed that the title phrase doesn't seem to appear elsewhere on the web.

Collections aren't OO -- at least, StronglyTypedCollection's aren't; they are orthogonal to OO, and need techniques outside the realm of OO to make them strongly typed, in parameterizing/specializing what they hold, typically via GenericProgramming.

General collection classes, like Array or Dictionary, are universally provided in OO languages, but such classes are not strongly typed, in the sense that e.g. if a method expects an Array of String, nothing prevents sending it an Array of Number instead.

To create StronglyTypedCollections is a matter of ParameterizedTypes?, GenericProgramming, template specialization, etc, e.g. Array<String>.

Since this is a frequently misunderstood subject, here's the central point: In a pure OO language, there is no static nor dynamic type safety for the contents of a collection; if a method requires Array of String, not any other kind of Array, it must check the contents of a passed Array by hand. In e.g. GenericProgramming, this kind of type safety is supported by the language.

This obviously doesn't cripple pure OO languages like Smalltalk; one can do nicely with general collections rather than StronglyTypedCollections. But I think it's an interesting point, and one of the justifications for GenericProgramming rather than pure OO programming.

And it's things like this that motivated the addition of GenericProgramming features to Java, for instance; it adds not just further convenience, but in some cases further type safety as well. -- DougMerritt

[Costin wishes to make a statement on the record, but dislikes it when his signed comments are edited, thus I have paraphrased and removed inappropriate phrasings, and his signature; the result is halfway between ThreadMode and DocumentMode, and may not perfectly reflect his feelings, but I want to move away from outright fighting ThreadMode and towards something a little closer to DocumentMode:]

[Paraphrase: Statically typed or dynamically typed, this is orthogonal to OO-ness of anything. At minimum this page should be renamed. At best this page is redundant; if you want to say "ParametricPolymorphism is useful" -- and not only for collections, by the way), and that ParametricPolymorphism is orthogonal to OO, then this piece of trivia has been already recorded on c2, without somebody needing to create the obtuse title CollectionsArentOo.] [In response to deleted/paraphrased text, the follow exchange occurred, which should also be refactored into something closer to DocumentMode (there appear to be some substantive points to be saved, but which are too-closely-bound to negative rhetoric to separate without some further thought): ]

Costin; why do virtually all of your posts contain the phrase "handwaving"? :)

At any rate, JavaArraysBreakTypeSafety quite nicely sums up the issue of container<base> and it's relationship with container<derived>; treating them covariantly is OK in the absence of mutation; otherwise they cannot be treated covariantly and still be type-safe, at least not without a runtime check. Since Smalltalk only has containers that can hold objects and no more specific type, it avoids the problem by definition--but suffers for it IMHO. Java arrays require runtime checks to make sure that you cannot insert a Base into a Derived[]; it requires this precisely because it allows Derived[] to be used in a context where Base[] is expected.

At any rate, I agree with you that the presence or absence of a subtype relationship betwen container<base> and container<derived> has little to do with whether collections are or aren't "OO". After all, the contained things can have subtype relationships (stuffing a derived into a container<base> does and ought to work--if C++, assuming pointers or references, naturally--and likewise, useful subtype relations can be found among different container types; lists and vectors might be subtypes of a more abstract "sequence", which is a refinement of a generic "collection". The C++ StandardTemplateLibrary doesn't use runtime polymorphism for this; but it does take advantage of template-expansion-time DuckTyping to form a de facto container hierarchy. Doug; I'm a bit puzzled by your recent posts on the "not OO" topic. If by "not OO" you mean "orthogonal to OO", OK... but you seem to be compartmentalizing each and every programming technique, trick, and feature into this paradigm or that paradigm. Many things transcend our definitions of "paradigms", many of which are artificial distinctions anyway. I'm not a MultiParadigmWeenie cause I dig knowing about lots of different programming models and care deeply about the difference; I'm a MultiParadigmWeenie precisely because I don't care. I want to write good code, and I don't give a damn whether it's OO or functional or whateverthehell else. Obviously, knowing about the dominant paradigms is useful, so I study it as much as I can; but I prefer not to worry about what technique lies where. I often feel sorry for the SmugSmalltalkWeenies who jettison perfectly good programming techniques because they aren't OO. If by "not OO", you mean "opposed to OO"; that would be wrong. But I suspect you mean the first meaning; you seem to have said so above. --ScottJohnson


Also related: ContraVsCoVariance, StronglyTypedCollection, RelationalBreaksEncapsulation, OoConflictsWithCollectionOrientation
CategoryNotOo, CategoryOopDiscomfort

EditText of this page (last edited November 15, 2013) or FindPage with title or text search