From: Tom <tom.primozic@gmail.com>
To: brogoff <brogoff@speakeasy.net>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Instruction selection in the OCaml compiler: Modules or classes?
Date: Fri, 23 Feb 2007 19:14:35 +0100 [thread overview]
Message-ID: <c1490a380702231014n46928637s7a5a2ea10809397b@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0702230756410.11798@shell4.speakeasy.net>
[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]
>
>
> 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
that.
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
[-- Attachment #2: Type: text/html, Size: 2438 bytes --]
next prev parent reply other threads:[~2007-02-23 18:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-22 14:38 Joel Reymont
2007-02-22 17:21 ` [Caml-list] " Tom
2007-02-22 17:38 ` Xavier Leroy
2007-02-22 19:55 ` Chris King
2007-02-22 19:59 ` Markus Mottl
2007-02-23 16:13 ` brogoff
2007-02-23 18:14 ` Tom [this message]
2007-02-23 19:28 ` [Caml-list] Instruction selection in the OCaml compiler: Modulesor classes? Andreas Rossberg
2007-02-24 2:51 ` skaller
2007-02-24 11:48 ` David Baelde
[not found] ` <4a708d20702240518l2c430b06r18fe64cabe5cbe9@mail.gmail.com>
2007-02-24 13:33 ` Lukasz Stafiniak
2007-02-24 14:58 ` [Caml-list] Instruction selection in the OCaml compiler:Modulesor classes? Andreas Rossberg
2007-02-24 17:39 ` skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c1490a380702231014n46928637s7a5a2ea10809397b@mail.gmail.com \
--to=tom.primozic@gmail.com \
--cc=brogoff@speakeasy.net \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox