Date: Wed, 18 Dec 1996 14:29:57 +0100
Message-Id: <199612181329.OAA08411@arthur.u-strasbg.fr>
From: Christian Boos <boos@arthur.u-strasbg.fr>
To: Jerome Vouillon <vouillon@clipper.ens.fr>
Subject: Private methods (was Re: Questions about class types)
In-Reply-To: <Pine.SUN.3.95.961217161441.20187A-100000@nave>
<Pine.SUN.3.95.961217161441.20187A-100000@nave>
[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