Questions about class types

Questions about class types

[Hendrik Tews]

Hello,

I want to write a module which provides a class with some
features, say

#module type A = sig
#  class b (unit)= method init : unit
#  end
#end;;

but I want to implement it via a class with more features, say

#module B = struct
#  class b () as self =
#    val a = ()
#    method init = self#f
#    method f = a
#  end 
#end;;	

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? As you can guess I would like additional methods to get
hidden when matching a class against a class type.

The first idea is to implement f as an instance variable (of
functional type) as well, but this gets very ugly as soon as
there are some mutually recursive f's.

The next idea was to specify only a type and some
functionality, not a class ie:

#module type A' = sig
#  val newb : unit -> < init : unit; .. >
#end;;
#
#module B' : A' = struct
#  class b () as self =
#    val a = ()
#    method init = self#f
#    method f = a
#  end
#
#  let newb () = new b ()
#end;;	

The disadvantage of this approach would be that a user of A'
can't use new, because he does not have access to the class.
To my surprise it did not type check, because

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

Even with explicit typing newb, ie substituting

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

I get the same error. So far I thought, that a class type is only
a abbreviation for something like < .. >. Where am I wrong?

Bye,

Hendrik Tews

-------------------------------------------------------------
e-mail:   tews@tcs.inf.tu-dresden.de
www:      http://www.inf.tu-dresden.de/~ht1
Console:  ithif18.inf.tu-dresden.de

Questions about class types

[Christian Boos]

Hello,


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 ?

 > The first idea is to implement f as an instance variable (of
 > functional type) as well, but this gets very ugly as soon as
 > there are some mutually recursive f's.

But this helps in some cases !

 > The next idea was to specify only a type and some
 > functionality, not a class ie:
 > 

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

  module type A' = sig
    val newb : unit ->  < init : unit >
  end

  module B' : A' =
    struct
      class b () as self =
        val a = ()
        method init = self#f
        method f = a
      end
 
      let newb () = (new b () :>  < init : unit >)
    end


This compiles fine !

-- Christian

Re: Questions about class types

[Hendrik Tews]

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

Re: Questions about class types

[Jerome Vouillon]

Hello,

> 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.

It is definitively not possible to hide methods in a class.  When a
method is redefined, it must keep the same type. The reason is that
other methods of the same class might invocate it, and thus expect it
to have a certain type. But if a method were hidden, its previous type
would also be hidden, and there would be no way to enforce a
redefinition of this method to have the right type.

> 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.

Type < init : unit; .. > is more general than type
b = < init : unit; f : unit > (the ellipsis is an unamed type
variable). So, your type cast produces no error (these two types can
be unified), but you cannot expect a function of type unit -> b to be
considered as having the more general type
  unit -> < init : unit; .. >.

Regards,

Jerome

Re: Questions about class types

[Jerome Vouillon]

> Ok, I think I see now what's going on: the eventually hidden method would
>  be overwritten. That's because the hashing is on the method's name only, but
> what if the name is extented by a stamp uniquely associated with the privacy
> scope of the method ?
> 
> i.e. one could have the classes:
> 
> class a as self =              |
>   val a = 1                    |  This is the "privacy scope" of class a.
>                                |
>   private method toto = a      |  Inside this, the method's name could be
>                                |  expanded "toto-123" for example ...
>   method use = self#toto       |
> end                            |
> 
> 
> class b as self =              |  
>   inherit a                    |
>                                |
>   val b = "one"                |  This is another "privacy scope".
>                                |
>   private method toto = b      |  Inside this one, the method's name could be
>                                |  expanded "toto-124".
>   method use = self#toto       |  Here, there is no way to access the former
> end                            |  method "toto" ... and therefore there's no
>                                |  conflict.
> 
> Maybe this could work ?

Right, one could indeed have private methods. But I am still looking
for a good notation for private method invocation...
The notation `self#toto' is not suitable (How would it be typed and
compiled ? How do one know whether `toto' make reference to a regular
or a private method ?).  And I would not like writing just `toto', as
this expression is somewhat misleading: it would not represent in this
case a variable access, but a function call. 

   Jerome