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