
Objects Are Not Abstract Data Types - bgray
http://stuartsierra.com/2009/12/14/objects-are-not-adts?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+StuartSierra+%28Digital+Digressions+by+Stuart+Sierra%29
======
gprisament
"Object-oriented languages, Liskov said, tend to conflate the concrete
representation of a type with the interface used to access it."

This is why I prefer C to C++. An opaque data type in C has a clean separation
of the interface from the implementation. C++ classes tend to have both
methods and implementation-dependent data specified in a single file. Granted,
one can write good or bad code in any language, but I've found C encourages
good behavior in this regard more than C++.

~~~
derefr
I really wish people could just abstain from using the built-in class
abstractions in their C++, instead of switching wholesale to C and losing all
of C++'s other niceties (templates, exceptions, less cruft on portability of
primitives, etc.) C++-without-classes is a really nice medium-level language,
one that's a lot better at being C than C is, and it'd be nice if more things
could be written in it. It would be perfect for the Linux kernel and GNOME,
for example.

However, as you've said, C++ encourages you to use its badly-thought-out class
abstractions, and that's what most people who "code C++" tend to know how to
do. Linus, I believe, disallowed C++ specifically because people would
gradually write the kernel into a maintainability corner, by modeling things
as hierarchies of classes without understanding the implications.

------
lmkg
What are the similarities and differences between working with a CLU-type
type/cluster separation for fields and methods, and a CLOS-style multi-method
approach, which has methods and generics standing free from objects and
classes? It seems like CLU follows a more traditional single-dispatch
paradigm, with the fields and the methods in different layers but bundled
together, while CLOS separates the methods not just from the fields but from
everything. But I haven't worked with either, so I'm just guessing. Can anyone
comment from experience?

~~~
mnemonicsloth
I'm clueless about CLOS and just learning Clojure. Corrections solicited,
grain of salt, yadda yadda:

1\. Clojure already provides multimethods, which can dispatch CLOS-style,
based on number/type of their arguments, or by an arbitrary predicate.

2\. To use your wording, while CLOS separates methods from "everything",
Clojure multimethods are even separated from _classes_. Other than being type-
aware enough to do dispatch, multimethods are conceptually just functions with
some extra testing on the front end.

3\. Implementation-wise, things seem to be different. Perusing the links
below, it seems the new functionality is intended to preserve
dynamism/performance when Java and Clojure objects interact.

4\. Grouping functions into logical chunks seems to be the other idea behind
protocols.

