Re: Questions about class types

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

Private methods (was Re: Questions about class types)

[Christian Boos]

[mail originellement destine en prive a Jerome Vouillon, mais finalement cela
peut interesser plus de monde !]


   Bonjour,

Je viens de me rendre compte d'une chose, suite a la lecture attentive de votre
mail, c'est qu'il est deja possible d'utiliser des methodes privees si les
variables (membres) sont en fait des valeurs fonctionnelles. 
Seulement on est alors limite par les restrictions generales en vigueur pour 
les variables, et qui ont deja fait l'objet de nombreux mails (le thread 
"Constructeurs en O'Caml" que je viens de relire). 

Jerome Vouillon wrote:
> [.....................] 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. 

Donc, si l'on peut tres bien ecrire:

class a p =
  val f = fun a b -> a+b*p
  method sym u v = (f u v, f v u)
end;;

il reste que 'self' reste inaccessible dans [f], et de ce fait, il est
 egalement impossible d'avoir acces aux methodes publiques.

Mais ne serait-il pas possible d'autoriser l'acces a 'self' dans les valeurs
de type fonctionnelles uniquement ? Qui plus est, pour eviter les effets de 
bord, il faudrait etendre la syntaxe du val pour pouvoir definir directement
(explicitement) des fonctions:

  class a () as self =
(*1*)    val f a b = 
      (* ici on pourrait acceder a 'self' sans probleme (comme si on etait dans
         une methode), enfin, en tout cas je ne vois pas de probleme,
         ce qui ne veut pas dire qu'il n'y en a pas ! *)
      ...

(*2*)    val f' = fun a b -> ... (* la, on ne pourrait pas, car on aurait tres 
                                   bien put ecrire: *)
(*3*)    val f'' = self#... ; fun a b -> ... (* qui pose probleme ! *)
  end

En plus de cela, les valeurs fonctionnelles declarees comme (*1*) pourraient
etre mutuellement recursives, comme les methodes. En fait, ca vaudrait presque
le coup de les declarer avec le mot-cle "fun" !


Au passage, j'en profite pour dire que je trouve que les 'initializers' sont
une tres bonne idee (effectivement, un constructeur n'est ni une methode
classique, ni une variable membre classique, donc le mieux est de rendre sa
particularite evidente).

Et j'en profite egalement pour demander si vous avez discute de l'idee de 
changer l'associativite de '#' de la facon dont je l'avais suggere (cad est-ce
que l'idee vous parait bonne/mauvaise/sans interet).


-- english version --


Hello,

When reading the following:

Jerome Vouillon wrote:
> [.....................] 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. 

I realized that in fact some kind of 'private method' is already available
through the use of instance variables of functional types. But then,
I remembered the thread about 'Constructors in O'Caml', and the limitations
of instance variables, specially the absence of self reference.

Indeed you can write:

class a p =
  val f = fun a b -> a+b*p
  method sym u v = (f u v, f v u)
end;;

But you can't access 'self' in [f]. This forbids by the same time the use of 
'public' methods from inside [f].

But wouldn't it be possible to allow the access to 'self' from inside instance
variables of functional types ? Moreover, you should be able to define 
directly a function using the val syntax, thus preventing you from accessing
'self' in side effects.

  class a () as self =
(*1*)    val f a b =  (* no problem here: you can safely access 'self' 
                         as if you were in a method *)
          ...

(*2*)    val f' = fun a b -> ... (* here there might be a problem,
                                    since you could have written it:
(*3*)    val f'' = self#... ; fun a b -> ... (* which is problematic ! *)
  end

  Additionaly, the functional values defined as in (*1*) could be mutually
recursive inside the scope of the class definition, as methods are.
You may even use the keyword "fun" instead of "val" for that !


  By the way, I would like to say that I completely support the idea of
'initializers' proposed by Jerome Vouillon some time ago.

  I would also ask the devellopers (at the risk of becoming irritating!) 
what they thought about my proposal for an alternative syntax for
message sending ('#') (it was 'change the associativity for allowing successive
message sending even in the presence of arguments').


-- Christian Boos

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