Re: Using modules and classes recursively

From: Markus Mottl (mottl@miss.wu-wien.ac.at)
Date: Tue Jan 12 1999 - 20:20:31 MET


From: Markus Mottl <mottl@miss.wu-wien.ac.at>
Message-Id: <199901121920.UAA12125@miss.wu-wien.ac.at>
Subject: Re: Using modules and classes recursively
To: bpr@best.com (Brian Rogoff)
Date: Tue, 12 Jan 1999 20:20:31 +0100 (MET)
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



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:17 MET