]> Brian Smith wrote: > John Max Skaller wrote: > >> Alessandro Baretta wrote: >> No. (class based) object orientation is utterly flawed as a paradigm, >> as can be seen by posing the trivial problem of representing any type > > > with a binary operator. > >> It just can't be done, the problem is called 'covariance problem'. >> >> I find it hard to state what the problem is here, but I'll try: >> the problem is you can write an unimplementable interface >> and not get a type error: >> >> struct X { virtual bool binop(X const&)const=0; }; > > > Do you really mean _all_ class-based object orientation? Don't > multimethods and/or overloading help in this case? I don't understand really. The requirment is for an interface specification and (the possibility of) multiple representations. Multimethods are just a slightly more sophisticated dispatch technique, they necessarily break object encapsulation, and there is still no way to represent n squared functions any way other than with n squared functions. :-) Does overloading help? Sure. It is the only solution. More precisely, a convenient syntax for naming the n squared functions. > > > bool equals(x : 'a, y : 'b) = false ; > bool equals(x : Integer, y : Integer) = x.intValue() = y.intValue() ; > bool equals(x : String, y : String) = (* compare all the chars *) ; Both these cases show a common representation. What is the type of x.intValue()? Obviously this is bogus. There is a total loss of abstraction. Clearly, the only type of Integer of any use at all is 'int'. Obviously won't work for 'long long int'. ;-) The second case is more interesting, since the String contents are concrete, but the representation of the sequencing of them internally is abstracted. In other words, different implementations can exist of the *same* type String. This is a good use of class based object orientation (providing one level of representation independence). Q: Why does it work? A: because the characteristic methods of the abstraction x.get(i) // get nth char x.set(i,c) // set ith char to c have *invariant* arguments. In particular, i and c are specific concrete types. > bool equals(x : String, y : Integer) = equals(x, y.toString()) ; Urg :-) > > This seems to be what Nice does. Nice is based on the > ML(less-than-or-equal) type system. > > Perhaps, your comments only apply to a certain subset of class-based > object-orietned languages? My comment applies to considering object orientation as a *paradigm*. It is language independent, entailing mutable objects, encapsulation, and subtyping (possibly via inheritance). Ocaml and C++ are both object oriented languages, and they are both better than pure ones precisely because classes are only one available technique. Classes are useful, dynamic *linear* dispatch is not to be sneered at. (and multimethod research is useful, to find 'almost linear' dispatch techniques). [linear dispatch uses an indexed table lookup, and so is constant time] -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners