Class/prototype-based OO

Class/prototype-based OO

[David Baelde]

Hi list,

After having had to learn Java, I was annoyed by the lack of subtyping
compared to OCaml. In Java two identical classes with different names
cannot be used identically. I then re-read Wikipedia's articles on
prototype-based [1] and class-based [2] OO. I used to be convinced
that OCaml was cited in the first category. It is not the case, and I
see now that the question is not trivial.

It is said that prototype-based OO is criticized for being too
dynamic, I believe that OCaml style of OO is an example of static
language having at least the most interesting features of
prototype-based OO.

Any opinion?

If I remember well, I didn't like the duck-typing article either,
which authors didn't seem to know OCaml. Our language makes the
boundary between static and dynamic languages more complex.

Cheers.
-- 
David

[1] http://en.wikipedia.org/wiki/Prototype-based_programming
[2] http://en.wikipedia.org/wiki/Class-based_OOP

Re: [Caml-list] Class/prototype-based OO

[skaller]

On Fri, 2006-08-25 at 09:51 +0200, David Baelde wrote:
> Hi list,
> 
> After having had to learn Java, I was annoyed by the lack of subtyping
> compared to OCaml. In Java two identical classes with different names
> cannot be used identically. I then re-read Wikipedia's articles on
> prototype-based [1] and class-based [2] OO. I used to be convinced
> that OCaml was cited in the first category. It is not the case, and I
> see now that the question is not trivial.
> 
> It is said that prototype-based OO is criticized for being too
> dynamic, I believe that OCaml style of OO is an example of static
> language having at least the most interesting features of
> prototype-based OO.
> 
> Any opinion?

Yeah, you're confused. Ocaml isn't using prototypes.

Languages like Cecil use prototypes. In this case,
you create an object at run time, and make similar
objects by cloning the original object.

This is entirely unrelated to the difference between
classes with nominal (named) typing (C++, Java)
and classes with structural typing (Ocaml).
 
There is no doubt whatsoever nominal typing is rubbish :)

The reason, trivially, is that any structurally based
typing can always be promoted to a nominally typed
system by simply adding a phantom nominal type
representing the 'name'.

On the other hand, structural typing solves a major
problem with nominal typing which destroys class based
object orientation entirely: the inability to devise
new algorithms which use objects satisfying certain
axioms -- in other words, an abstraction -- unless the
class was derived from, or specified to implement,
that particular abstraction when it was designed:

	class X : public Abstraction { ..

in C++.

The number of possible interfaces a given class may have
is combinatorial in the number of methods, and so it
is not tenable to name them all in advance, but if you
want to use one NOT named previously, after creating
it you have to invade every instance class specification
and add a new interface to its base-class or implements list,
breaking the open/closed principle on which dynamic dispatch
and the very notion of encapsulation central to OO actually
rests:

	class X : public Abstraction, public NewAbstraction {
	//                          ^^^^^^^^^^^^^^^^^^^^^^^^
	// violation of encapsulation!

Thus, from a software engineering viewpoint, nominal typing
is not a viable option .. which is one reason programming
in Java or C++ using OO sucks.

In Ocaml, it works much better because you can actually
write algorithms which work with many different types,
provided only they support the 'right methods'.

You should note structural typing does NOT solve the
problem, but it does reduce the problem. It doesn't
solve the problem, because methods have names which
count in the class signature. It's the old problem
all over again, but at a lower level.

And even if this weren't so it STILL wouldn't solve
the problem, because more than one data type can
represent the same thing .. so even the types may
be semantically, but not physically, equivalent:

	int * float // a pair of an int and a float
	float * int // woops, ANOTHER type, same information!

In ALL these cases *including* the nominal typing situation
there is a universal solution: wrapping/proxies/forwarding
functions/delegation/mapping as you want to call it, in which
you build the required interface, and implement its methods
by dispatching to an object of the 'wrong' type.

However this is not only messy .. particularly in C++
since it has no garbage collection .. it also tends to 
destroy subtyping.

There is a point where all this housekeeping is so unreliable
and difficult you'd be better off with dynamic typing,
such as that provided by prototype based OO, or other
kinds of object systems such as that used by Python
(which is more or less prototype based but actually
uses classes rather than cloning prototypes).

The boundary is probably close to the amazing feat of
constructing an Ocaml binding for GTK.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Class/prototype-based OO

[Ted Kremenek]

On Aug 25, 2006, at 4:31 AM, skaller wrote:

> Thus, from a software engineering viewpoint, nominal typing
> is not a viable option .. which is one reason programming
> in Java or C++ using OO sucks.
>
> In Ocaml, it works much better because you can actually
> write algorithms which work with many different types,
> provided only they support the 'right methods'.

While the structural typing in Ocaml is wonderful (I really love it),  
there are missing features of the OO system in OCaml that can be  
particularly bothersome, and are worth considering when comparing the  
OO features of Ocaml with other languages (including those that use  
nominal typing).

For example, from what I can tell it appears that Ocaml lacks real  
support for "downcasts" in the language, which require run-time type  
information (RTTI) and run-time checks.  In the context of structural  
typing, I am talking about "casting" an object with a type with a  
given set of method signatures to another type with an extended set  
of method signatures.  Whether or not you agree downcasts are a good  
thing, it is one thing to take into account when comparing the OO  
features of different languages (and this is a feature that both C++  
and Java have that OCaml does not).  In general, I don't believe the  
OO system in Ocaml supports any kind of RTTI, which enables features  
such as downcasts and reflection.  All of the type checking of  
objects in OCaml is static, which is very nice but often insufficient.

Actually, if I am wrong about this I would be very happy if someone  
out there can point this out.  Certainly one can implement downcasts  
using Obj.magic and some hand-crafted RTTI, but that is obviously not  
a desired solution.

Re: [Caml-list] Class/prototype-based OO

[skaller]

On Mon, 2006-08-28 at 20:11 -0700, Ted Kremenek wrote:

> While the structural typing in Ocaml is wonderful (I really love it),  
> there are missing features of the OO system in OCaml that can be  
> particularly bothersome, and are worth considering when comparing the  
> OO features of Ocaml with other languages (including those that use  
> nominal typing).
> 
> For example, from what I can tell it appears that Ocaml lacks real  
> support for "downcasts" in the language, which require run-time type  
> information (RTTI) and run-time checks.

Yes, indeed, this is wonderful! For the first time programmers
learn the truth.

Ocaml does not pander to the false god of Object Orientation.

>   In the context of structural  
> typing, I am talking about "casting" an object with a type with a  
> given set of method signatures to another type with an extended set  
> of method signatures. 

There is no need. Use the proper technology: variants.

They provide run time type information on which you can
dispatch.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Class/prototype-based OO

[brogoff]

On Tue, 29 Aug 2006, skaller wrote:
> Yes, indeed, this is wonderful! For the first time programmers
> learn the truth.
>
> Ocaml does not pander to the false god of Object Orientation.

Putting aside the loaded nature of the statement, Ocaml does not only
support OO directly but any future enhancement has to work with the
current Ocaml object system, which would seem to be a high bar for
introducing new typing features.

It would be more orthogonal IMO if there were no objects but rather some kind
of polymorphic records dual to polymorphic variants, and an extended module
system (what happened to the mixin modules?) which could handle other aspects
of OO. Maybe a future ML will go in that direction?

That's not saying that OO is "false", just that I think of parameterized
modules as a fundamental ML feature and my sense is that the class system
sits uneasily with modules.

-- Brian

Re: [Caml-list] Class/prototype-based OO

[Gerd Stolpmann]

Am Montag, den 28.08.2006, 20:11 -0700 schrieb Ted Kremenek:
> On Aug 25, 2006, at 4:31 AM, skaller wrote:
> 
> > Thus, from a software engineering viewpoint, nominal typing
> > is not a viable option .. which is one reason programming
> > in Java or C++ using OO sucks.
> >
> > In Ocaml, it works much better because you can actually
> > write algorithms which work with many different types,
> > provided only they support the 'right methods'.
> 
> While the structural typing in Ocaml is wonderful (I really love it),  
> there are missing features of the OO system in OCaml that can be  
> particularly bothersome, and are worth considering when comparing the  
> OO features of Ocaml with other languages (including those that use  
> nominal typing).

That sounds a bit like as if the OO language with more features was the
better one. The problem is that certain features are incompatible with
each other, at least in a practical sense, i.e. you cannot have good and
efficient implementations for all.

> For example, from what I can tell it appears that Ocaml lacks real  
> support for "downcasts" in the language, which require run-time type  
> information (RTTI) and run-time checks.  

In theory, RTTI is possible in O'Caml. But it is very costly: Object
types are complex structures and not only names. So any downcast would
be a very expensive operation (a full type check).

> In the context of structural  
> typing, I am talking about "casting" an object with a type with a  
> given set of method signatures to another type with an extended set  
> of method signatures.  Whether or not you agree downcasts are a good  
> thing, it is one thing to take into account when comparing the OO  
> features of different languages (and this is a feature that both C++  
> and Java have that OCaml does not).  In general, I don't believe the  
> OO system in Ocaml supports any kind of RTTI, which enables features  
> such as downcasts and reflection.  All of the type checking of  
> objects in OCaml is static, which is very nice but often insufficient.

Please note that OCaml is not only OO, so if you observe that you need
downcasts often, you probably have an inappropriate programming style.

For example, if you want to have a user-extensible data structure, you
normally implement it with modules and parametric polymorphism. If the
user of this structure wants to store different things into the same
structure, one can define a variant type. (Well, I know that OO
enthusiasts have a lot of prejudices against variants, mostly because
they never saw which role variants can play in a polymorphism-rich
language.)

> Actually, if I am wrong about this I would be very happy if someone  
> out there can point this out.  Certainly one can implement downcasts  
> using Obj.magic and some hand-crafted RTTI, but that is obviously not  
> a desired solution.

Certainly not this way. Simply use exceptions for home-made RTTI:

class type foo = ...

exception Foo of foo

class foo_class : foo =
object(self)
   ...
   method downcast = raise(Foo(self : #foo :> foo))
end


let downcast_foo (obj : < downcast : unit; ..>) =
  try obj # downcast
  with Foo x -> x
     | _ -> failwith "This is not a foo!"


Although this is restricted to monomorphic types please note that the
other languages you mention only have this sort of types.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: [Caml-list] Class/prototype-based OO

[Ted Kremenek]

On Aug 29, 2006, at 5:03 AM, Gerd Stolpmann wrote:

> In theory, RTTI is possible in O'Caml. But it is very costly: Object
> types are complex structures and not only names. So any downcast would
> be a very expensive operation (a full type check).

Of course, but this cost would only be incurred during the downcast.   
Thus people who do not need to use the operation will not pay for  
it.  Of course, the RTTI information comes with a space cost.

Re: [Caml-list] Class/prototype-based OO

[Ted Kremenek]

On Aug 29, 2006, at 5:03 AM, Gerd Stolpmann wrote:

> Certainly not this way. Simply use exceptions for home-made RTTI:
>
> class type foo = ...
>
> exception Foo of foo
>
> class foo_class : foo =
> object(self)
>    ...
>    method downcast = raise(Foo(self : #foo :> foo))
> end
>
>
> let downcast_foo (obj : < downcast : unit; ..>) =
>   try obj # downcast
>   with Foo x -> x
>      | _ -> failwith "This is not a foo!"
>
>
> Although this is restricted to monomorphic types please note that the
> other languages you mention only have this sort of types.

This is a cute idea.  I'm glad that you mentioned the point about  
monomorphic types.  Hypothetically, is there any need for  
"polymorphic" downcasts?

Re: [Caml-list] Class/prototype-based OO

[Jacques Garrigue]

From: Ted Kremenek <kremenek@cs.stanford.edu>

> While the structural typing in Ocaml is wonderful (I really love it),  
> there are missing features of the OO system in OCaml that can be  
> particularly bothersome, and are worth considering when comparing the  
> OO features of Ocaml with other languages (including those that use  
> nominal typing).
> 
> For example, from what I can tell it appears that Ocaml lacks real  
> support for "downcasts" in the language, which require run-time type  
> information (RTTI) and run-time checks.  In the context of structural  
> typing, I am talking about "casting" an object with a type with a  
> given set of method signatures to another type with an extended set  
> of method signatures.  Whether or not you agree downcasts are a good  
> thing, it is one thing to take into account when comparing the OO  
> features of different languages (and this is a feature that both C++  
> and Java have that OCaml does not).  In general, I don't believe the  
> OO system in Ocaml supports any kind of RTTI, which enables features  
> such as downcasts and reflection.  All of the type checking of  
> objects in OCaml is static, which is very nice but often insufficient.

The question of downcasts in ocaml is a recurring one.
There is indeed no way to downcast an object to an arbitrary
superclass of its dynamic class.
But a major question here is whether we want to be able to do that or
not, particularly in a structural type system.
"Universal" downcasting would mean that you would be able to revert
any ocaml object to its original object type, as long as you know
this type (structurally). This clearly breaks almost any form of
abstraction. So this means that programs that currently guarantee,
through the use of subtyping or private row types, that some methods
of an object are not visible, could be easily broken.
This is a rather philosophical problem. Do we really need abstraction
to be unbreakable? From a theoretical point of view yes, while
practicians do not always agree.
Another problem with "universal" downcast is that it would be
extremely costly. Checking subtyping with structural types is a rather
heavy weight algorithm, which can takes several seconds in some
cases. It looks a bit like trying to break encryption while running a
program...

For the above reasons I think that "universal" downcast in ocaml is
not a good idea. 

Now, one might want some weaker, explicit form of allowing downcasts.
Actually some proposal was done already in the last century:
http://groups.google.com/group/fa.caml/browse_thread/thread/48fc2b87effc1097/e3ef9dab723b7c52
Basically, it allowed to declare a posteriori a downcasting
hierarchy, giving subtyping relations between classes, that was
checked by the type-checker. One could then downcast objects of a
certain class (each object already contains a pointer to its class, so
this can be checked at untime) to any type declared as supertype.
The idea was not bad, and it does not completely break abstraction: if
you do not have a class declaration in your scope, you cannot add it
to the downcasting hierarchy. But there are hard to overcome
limitations:
* only monormophic classes can be added to the hierarchy
  (not polymorphic ones or immediate objects)
* it is easy to forget to add a subclass to the hierarchy, and then
  there is no way to downcast it, even to one of its superclasses
  appearing in the hierarchy

One could think of other approaches, but I'm not sure there is a
canonical one to add to the language, that would make everybody
happy.

On the other hand, there are various ways to simulate downcasting.
My favorite one is already described in the above thread: keep objects
you may want to downcast in an hash table.

  let memorize o table = Hashtbl.add table (o :> < >) o
  val memorize : (< .. > as 'a) -> (<  >, 'a) Hashtbl.t -> unit = <fun>

Now, you just need to keep one hash table for each target supertype,
and can then downcast any object in this hash table to this supertype.
Using object identity is a bit less efficient than using the class
pointer, but it partially solves the problem of polymorphic classes
and immediate objects: any subtype of a given type can be added to the
table, even if it is not from a monomorphic class.
Note that using a normal approach causes a memory leak, but using a
weak hash table solves that problem. See Remy Vanicat's Weak_memo for
that:
http://remi.vanicat.free.fr/ocaml/hweak/

Since this approach does not modify the compiler, or use any unsafe
feature, it does not break abstraction in any way.

Independently of downcasting, RTTI would also be needed for providing
more information in the debugger. But there seems not to be much
demand for that.

Jacques Garrigue

Re: [Caml-list] Class/prototype-based OO

[skaller]

On Thu, 2006-08-31 at 10:11 +0900, Jacques Garrigue wrote:
> From: Ted Kremenek <kremenek@cs.stanford.edu>

> Since this approach does not modify the compiler, or use any unsafe
> feature, it does not break abstraction in any way.

If you re-read that claim .. you can see that Ocaml is used
for something *other* than programming.

It is used to *prove* the safety of a technique. Such high
level reasoning is only possible because of the rigid adherence
to type safety.

The difference between Jacques 'Hashtable' for downcasts
and system generated RTTI is that the latter would have
to be enshrined in the type system, whereas the former,
whilst potentially performing the same function if used
systematically, exhibits its own typing within the
type system.

So in fact, as is typical of advanced languages, one could
make a claim for the addition of some feature, by demonstrating
it can be done already as sugar .. the demonstration then
proves safety and inspires the implementation .. and in 
particular the typing of it.

Most interestingly here .. with campl4 as a standard tool
you can do quite a bit of such sugaring yourself!

> Independently of downcasting, RTTI would also be needed for providing
> more information in the debugger. But there seems not to be much
> demand for that.

I would note it is difficult to judge the utility of a missing
feature :)

Try to tell someone in the C++ community that C++ is severely 
constrained because it doesn't have first class lexically
scoped functions, variants, or pattern matching .. even
if you explain what they are they'll just say "Oh, we can
do that this way .. but don't have much call for it".

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Class/prototype-based OO

[Jacques Garrigue]

From: skaller <skaller@users.sourceforge.net>

> > Independently of downcasting, RTTI would also be needed for providing
> > more information in the debugger. But there seems not to be much
> > demand for that.
> 
> I would note it is difficult to judge the utility of a missing
> feature :)
> 
> Try to tell someone in the C++ community that C++ is severely 
> constrained because it doesn't have first class lexically
> scoped functions, variants, or pattern matching .. even
> if you explain what they are they'll just say "Oh, we can
> do that this way .. but don't have much call for it".

Here you have to read between lines :-)
I am a user of the debugger, and I also use objects at times, so I
have a personal interest in having better support for objects in the
debugger, through RTTI for instance. But this would be quite a bit of
work, so this is difficult to justify if I'm the only user. Hence the
above wording...
If you think of it, debugging contains all the difficulties of RTTI,
but without the justification for _not_ having it, that is, you clearly
want to break abstraction when debugging. So that to do things
properly, we would even want to now dynamic type information about
polymorphic types, which is even harder than for objects.

Jacques Garrigue

Re: [Caml-list] Class/prototype-based OO

[skaller]

On Thu, 2006-08-31 at 15:36 +0900, Jacques Garrigue wrote:
> From: skaller <skaller@users.sourceforge.net>
 
> > Try to tell someone in the C++ community that C++ is severely 
> > constrained because it doesn't have first class lexically
> > scoped functions, variants, or pattern matching .. even
> > if you explain what they are they'll just say "Oh, we can
> > do that this way .. but don't have much call for it".
> 
> Here you have to read between lines :-)

Spying between the cracks between the boards whilst ROFL?

> I am a user of the debugger, and I also use objects at times, so I
> have a personal interest in having better support for objects in the
> debugger, through RTTI for instance. But this would be quite a bit of
> work, 

.. especially in the native code system ..

> so this is difficult to justify if I'm the only user. Hence the
> above wording...

> If you think of it, debugging contains all the difficulties of RTTI,
> but without the justification for _not_ having it, that is, you clearly
> want to break abstraction when debugging. 

Good point.

> So that to do things
> properly, we would even want to now dynamic type information about
> polymorphic types, which is even harder than for objects.

It is my guess (and only a guess!) that there is a balance
between run time checks and compile time checks.

Typing is always an abbreviation (abstraction) and sometimes
stronger or weaker than desired: for example array bounds
checks at run time, because the type system doesn't cope
with array sizes as part of the type.

All compilers do this. Some delegate a lot more
to run time than others eg Java: I pick Java because
contrary to popular opinion it is basically a dynamically
typed language, with a bit of static typing thrown in
for a few scalar types :)

C++ tends to err the other way: it is basically
statically typed, with exceptions and casts using RTTI.

Plus of course in *all* cases programmers spend a lot
of time implementing their own application specific kind
of run time typing .. because in some sense that is what
a program does: there is no clear boundary between
the concept of 'type' and 'data'.

The real issue here is surely how to do dynamic typing
systematically and coherently *within* the confines
of static typing regime.

The most interesting recent example I've seen of this
is in Alain's XDuce stuff, where 'regular expression'
actually becomes a type not a data structure.

In this case, programmer want so often to play with
XML and keep repeating the same run time coding patterns,
it is worthwhile enriching their environment with a typing
regime based on those patterns. This is a very beautiful
piece of work!

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net