English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Instruction selection in the OCaml compiler: Modules or classes?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-02-23 (18:14)
From: Tom <tom.primozic@g...>
Subject: Re: [Caml-list] Instruction selection in the OCaml compiler: Modules or classes?
> I use classes less frequently (but as Markus points out they are for the
> most part much more pleasant than Java or C++ classes) so my gut feeling
> is that their abilities should be subsumed in the module system (mixin
> modules?) and the record system.

I think you should take a look at another currently active thread  -
"Feature request : Tuples vs. records". One of the red lines there is the
comparison of structural versus nominal typing - classes and objects
belonging to the former, and modules and records to the latter. Some say
that structural typing features (objects, along with Polymorphic Variants)
are an appreciated alternative to the "rigid" nominal typing of OCaml
(variants, records, modules). That is why I believe that classes should
exist as a separate entity (I'm not that much in favour of polymorphic
variants - they weaken the type checking process too much in my opinion, and
I have yet to see a good use for them), so that one can use them when one
needs sharing - which records (and conventional inheritance-based object
systems) don't provide.

A criticism of OOP (available at
http://www.geocities.com/tablizer/oopbad.htm) addresses the issue that
although conventional class systems (that is, having nominal typing, not
structural) are supposed to be "nature like" (OO proponents claim that
objects are more suitable to modelling things as they are in nature), they
often lack the dynamic aspect of the nature, the adaptability - for example,
they cannot change class, and are usually adapted to one function only, or
model a functionality forcefully "adapted" to the tree-like
inheritance-based structure. OCaml objects seem a great alternative for

The way I see things, or rather the way I dream things, is having modules
simply as namespaces, having extensible records (records that have nominal
subtyping - inheritance, so that parts of records can be shared - very
useful in GUI implementation, in my opinion) with multiple dispatch, and
having structurally typed object system, like the one in OCaml. I hope I
will succeed in implementing such a system one day.

- Tom