Browse thread
[Caml-list] Protected methods
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jacques Garrigue <garrigue@k...> |
| Subject: | Re: [Caml-list] Protected methods |
From: Alessandro Baretta <alex@baretta.com> > Gerd Stolpmann wrote: > > No, you cannot restrict the type of classes by signatures. > > The only way I know to protect a method is to define an opaque > > type that is hidden by the signature, e.g. > > > > sample.ml: > > > > type protector = unit > > > > class a = > > object > > method m () = ... > > ... > > end > > > > sample.mli: > > > > type protector > > > > class a : > > object > > method m : protector -> XXX > > ... > > end > > > > You cannot call m from other modules because you cannot create values > > for the type "protector". > > > > Gerd > > Effective, definitely, but practical? Is this not supposed > to be a feature of any general purpose object oriented language? Actually, this seems perfectly practical. If you have some good reason to "protect" a method, you can do it cleanly. By the way, ocaml is not a general purpose object-oriented languages, but a general purpose functional language with object-oriented features. In particular, encapsulation is supported by the module system rather than the class system. Even in object-oriented languages, I've seen heated discussions on whether using friend classes was good style or not. > Anyway, for the meantime I'll keep the method public, and > make sure I don't use it anywhere except where it makes > sense, and I'll wait for some more insight from the developers. Note that in many cases there are other ways to obtain the expected behaviour. For instance, if only one specific object is supposed to use a method, you might register a private callback with it rather than the other way round. Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners