Re: [Caml-list] productivity improvement

[John Max Skaller <skaller@ozemail.com.au>]

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