caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Hendrik Tews <tews@tcs.inf.tu-dresden.de>
Cc: caml-list@margaux.inria.fr
Subject: Re: Questions about class types
Date: Tue, 10 Dec 1996 12:10:50 +0100	[thread overview]
Message-ID: <199612101110.MAA11392@ithif18.inf.tu-dresden.de> (raw)
In-Reply-To: <199611211710.SAA08291@arthur.u-strasbg.fr> (message from Christian Boos on Thu, 21 Nov 1996 18:10:27 +0100)

Hello,

sorry for answering so late. I had some holidays at the end of
November. 

Christian Boos wrote:

   Hendrik Tews writes:
    > ...
    > Unfortunately B does not match A, because (as it is written in
    > the documentation under 4.9.2) one can add additional instance
    > variables, but no additional methods. What is the reason for
    > this?

   That's a good question. Maybe O'Caml will add private methods some day ?

I am not sure what you exactly mean by "private methods". I am
looking for means to distinguish different access privilegs to an
object. In a more realistic example (which uses more types than
just unit) one would implement a service through a couple of
objects. One of them would provide the interface of the service
to the outside world. But in a distributed environment it might
be useful to update the state of the interface object
asyncronously. Therefore the interface object needs some methods
in addition to the methods for the interface. (In C++ I would use
a friend directive in such a case)

In ocaml I could hide all the additional objects in a module
implementation. But so far it is not possible to hide methods via
signature matching.

   This is a good idea. You're mistake was on using the ellipsis '..' which 
   doesn't seem to be needed in your example.

You are right. I don't need the ellipsis.

But I still don't understand the type error I got:

   Values do not match:
     val newb : unit -> b
   is not included in
     val newb : unit -> < init : unit; .. >

If b does not match  < init : unit; .. >  then the type cast in 

#  let newb () : < init : unit; .. > = ((new b ()) : < init : unit; .. >)

should produce an error. On the other side if the type cast is
valid, then the types should match.


Greetings,

Hendrik




  reply	other threads:[~1996-12-11 10:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-11-21 13:57 Hendrik Tews
1996-11-21 17:10 ` Christian Boos
1996-12-10 11:10   ` Hendrik Tews [this message]
1996-12-11 13:16     ` Jerome Vouillon
     [not found] <199612171154.MAA03264@arthur.u-strasbg.fr>
1996-12-17 16:06 ` Jerome Vouillon

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=199612101110.MAA11392@ithif18.inf.tu-dresden.de \
    --to=tews@tcs.inf.tu-dresden.de \
    --cc=caml-list@margaux.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;
as well as URLs for NNTP newsgroup(s).