Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Markus Mottl <mottl@miss.wu-wien.ac.at>
To: bpr@best.com (Brian Rogoff)
Cc: caml-list@inria.fr (OCAML)
Subject: Re: Using modules and classes recursively
Date: Tue, 12 Jan 1999 20:20:31 +0100 (MET)	[thread overview]
Message-ID: <199901121920.UAA12125@miss.wu-wien.ac.at> (raw)
In-Reply-To: <Pine.BSF.4.05.9901121012350.24045-100000@shell5.ba.best.com> from "Brian Rogoff" at Jan 12, 99 10:49:59 am

> On Tue, 12 Jan 1999, Xavier Leroy wrote:
> > > Is it impossible to have modules and classes combined recursively?
> > 
> > Currently, yes.  A module definition cannot be mutually recursive with
> > any other definition (type, class, or another module).  This raises a
> > number of difficult typechecking and compilation problems that are
> > still largely open.  I agree this is probably the most irritating
> > restriction of ML modules.
> 
> A similar restriction also exists in Ada, i.e., two package specifications
> cannot "with" (open) each other. One workaround for the case where you
> have mutually dependant tagged types (classes) in separate package specs
> is to break the cycle by creating a dummy parent type for each of the 
> dependant tagged types and using those in place of the type which would 
> cause the problem, in this case a "foo_dummy_parent set" would replace foo
> in the problem spots, foo would inherit from foo_dummy_parent and the
> foos that go into the set would have to be coerced to foo_dummy_parent.
> 
> I think this trick will work in OCaml too, but I haven't tried.
> 
> -- Brian

That would generally be a fine idea - I am sure it would work (I
have also not tried yet)! But unfortunately this won't work with my
classes, because they cannot be subtypes of their ancestor: they all
inherit from another class that has a method with the "'self"-type in
its signature. This "'self"-type is automatically redefined in every
(sub-)class, so the signature of the child class does not match the one
of its dummy parent class. It would only do so if this method didn't
exist in the dummy parent, but unfortunately, I have to access this
method for all objects in the set, so I cannot leave it away...

My last posting about "subtypes and inheritance" dealt with this problem.
Has already someone found a solution to this? - To me this is really
a big shortcoming, because it does not allow me to build larger class
hierarchies, where things like the "'self"-type or otherwise redefined
signatures of methods are very likely to occur.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl




      reply	other threads:[~1999-01-13 11:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-09 20:24 Markus Mottl
1999-01-12 17:29 ` Xavier Leroy
1999-01-12 18:49   ` Brian Rogoff
1999-01-12 19:20     ` Markus Mottl [this message]

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=199901121920.UAA12125@miss.wu-wien.ac.at \
    --to=mottl@miss.wu-wien.ac.at \
    --cc=bpr@best.com \
    --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