Re: [Caml-list] Protected methods

Re: [Caml-list] Protected methods

[Jacques Garrigue]

From: Alessandro Baretta <alex@baretta.com>
> > Actually, this seems perfectly practical.
> > If you have some good reason to "protect" a method, you can do it
> > cleanly.
> 
> I would not call adding a fake type a clean solution. It's 
> not idiomatic. A "protected" keyword is cleaner and easier 
> to handle. Although it might be very tricky to implement in 
> a language with type inference.

Actually, this is just an alternative model for protection:
give all your clients the key, and don't give it to other people.
This makes sense. The key can be a dummy only because the type system
guarantees that you cannot forge its type.
The problem with a "protected" keyword is that it should be given a
semantics. Since an object type is structural (does not belong to a
specific module), this is unclear how you can define where a protected
method should be accessible.

In practice, I probably won't do it that way, but this would require a
deeper knowledge of your problem.
For instance, if you want to show an internal state to a limited
number of clients, you can just have a method returning this state
with an abstract type. That's certainly more natural.

> How about the following pseudocode? Is it sensible/viable?
> 
> let module M : sig
>    class type public = object <public_methods> end
>    val make_public : unit -> public
> end = struct
>    class type public = object <public_methods> end
>    class protectd =
>      object (self : #public)
>      <public_methods>
>      <protected_methods>
>    end
>    let make_public () -> (new protected :> public)
> end
> 
> If this a working alternative, I would prefer over both the 
> protector type and the protected keyword: clean, simple, and 
> idiomatic.

This is both sensible and viable.
The only weakness is that you won't be able to inherit from the public
version of your class, since it is not a class but only a type.
If you need to inherit, you should also export the protected version,
and make sure that all your constructors apply a similar coercion to
hide protected methods.

This inheritance problem is the only reason I didn't suggest this
approach first, but it is certainly simpler.

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

[Caml-list] Protected methods

[Alessandro Baretta]

I'm trying to get the semantics of protected methods of C++. 
I have a class with a method that is not meaningful for the 
outside world, but different instances of this class should 
be able to invoke this method on one another.

I need something like the following pseudocode:

class a =
object
   method protected m = ...
   method m2 (obj:a) = a # m
end

I understand this can be obtained by creating a container 
module for class a and restricting the type of a through the 
module signature. I read the manual but was unable to figure 
out the syntax to do this. Would anyone be so kind as to 
lend a hand?

Thank you very much.

Alex

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

Re: [Caml-list] Protected methods

[Gerd Stolpmann]

Alessandro Baretta wrote:
> I'm trying to get the semantics of protected methods of C++. I have a 
> class with a method that is not meaningful for the outside world, but 
> different instances of this class should be able to invoke this method 
> on one another.
> 
> I need something like the following pseudocode:
> 
> class a =
> object
>   method protected m = ...
>   method m2 (obj:a) = a # m
> end
> 
> I understand this can be obtained by creating a container module for 
> class a and restricting the type of a through the module signature. I 
> read the manual but was unable to figure out the syntax to do this. 
> Would anyone be so kind as to lend a hand?

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
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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

Re: [Caml-list] Protected methods

[Alessandro Baretta]

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?

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.

Thank you very much, Gerd.

Alex

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

Re: [Caml-list] Protected methods

[Jacques Garrigue]

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

Re: [Caml-list] Protected methods

[Alessandro Baretta]

Jacques Garrigue wrote:
>>>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.

I would not call adding a fake type a clean solution. It's 
not idiomatic. A "protected" keyword is cleaner and easier 
to handle. Although it might be very tricky to implement in 
a language with type inference.

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

This is too big an issue for me. I only expressed the need I 
perceive for a construct to enable different instances of 
the same class to call methods on their siblings which are 
not visible to the general public. What I really want is a 
way to restrict through a type coercion the type of my 
"autofriendly" class.

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

How about the following pseudocode? Is it sensible/viable?

let module M : sig
   class type public = object <public_methods> end
   val make_public : unit -> public
end = struct
   class type public = object <public_methods> end
   class protectd =
     object (self : #public)
     <public_methods>
     <protected_methods>
   end
   let make_public () -> (new protected :> public)
end

If this a working alternative, I would prefer over both the 
protector type and the protected keyword: clean, simple, and 
idiomatic.

> 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

Hrmmm.... uuuhhh.... yes? What's it mean?

Thank you very much, Jacques, for taking time to answer my 
former post.

Alex

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

Re: [Caml-list] Protected methods

[Jacques Garrigue]

From: Alessandro Baretta <alex@baretta.com>

> How about the following pseudocode? Is it sensible/viable?
> 
> let module M : sig
>    class type public = object <public_methods> end
>    val make_public : unit -> public
> end = struct
>    class type public = object <public_methods> end
>    class protectd =
>      object (self : #public)
>      <public_methods>
>      <protected_methods>
>    end
>    let make_public () -> (new protected :> public)
> end

Actually, after a more thorough look at your code, I'm not sure of
what you're trying to achieve with it.  Applied directly, it seems
that it would give you no more than private methods: you can not use
them outside of the class.

And I've found a better idiom, that should do about anything you want.

module M : sig
  type hidden
  class type public = object < public methods >  method full : hidden end
  val make_public : unit -> public
  class virtual protected : object ('a)
    < public methods >
    < protected methods >
    method full : 'a
  end
end = struct
  class protected = object (self)
    < public methods >
    < protected methods >
    method full = self
  end
  type hidden = protected
  class type public = object < public methods >  method full : hidden end
  let make_public () = (new protected : protected :> public)
end

The point is that now you can access the protected methods while
your code appears in the same module, through the full method (which
just returns self, but with its protected methods accessible), but not
from outside the module (hidden is abstract).

Note also how I exported protected as virtual: this way you cannot
create objects from it, but you can still use it through inheritance.
If you don't need to inherit, you don't have to export it though, and
then you don't have to distinguish protected and hidden either.

Here is a concrete instance of that, to verify the type checking:

module M : sig
  type hidden
  class type public = object method pub : int  method full : hidden end
  val make_public : unit -> public
  val call_prot : public -> int
  class virtual protected : object ('a)
    method pub : int
    method prot : int
    method full : 'a
  end
end = struct
  class protected = object (self)
    method prot = 1
    method pub = self#prot
    method full = self
  end
  type hidden = protected
  class type public = object method pub : int  method full : hidden end
  let make_public () = (new protected : protected :> public)
  let call_prot (o : public) = o#full#prot
end

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

Re: [Caml-list] Protected methods

[Alessandro Baretta]

Jacques Garrigue wrote:
> 
> Actually, this is just an alternative model for protection:
> give all your clients the key, and don't give it to other people.
> This makes sense. The key can be a dummy only because the type system
> guarantees that you cannot forge its type.
> The problem with a "protected" keyword is that it should be given a
> semantics. Since an object type is structural (does not belong to a
> specific module), this is unclear how you can define where a protected
> method should be accessible.

I would be happy enough if protected methods were accessible 
to other instances of the same class. This would be easy to 
implement in O'Caml's type system, because the only place 
where protected methods are visible is between the "object" 
and "end" keywords. Nowhere else would the type system need 
to account for the presence of protected keywords.

class a = object private method m = let x = new a in x # m end

> In practice, I probably won't do it that way, but this would require a
> deeper knowledge of your problem.
> For instance, if you want to show an internal state to a limited
> number of clients, you can just have a method returning this state
> with an abstract type. That's certainly more natural.

I fully agree. But what do you do when an instance of class 
a holds other instances of class a which must collaborate 
with the first in order to achieve the functionality of the 
first? One possibility would be have define two classes: a 
front-end, with only the methods which should be generally 
available, and a backend, inheriting from the first and 
adding those methods that are only meaningful for the 
front-end. Otherwise, you define only one class and add a 
protected keyword for these latter methods.

>>How about the following pseudocode? Is it sensible/viable?
>>
>>let module M : sig
>>   class type public = object <public_methods> end
>>   val make_public : unit -> public
>>end = struct
>>   class type public = object <public_methods> end
>>   class protectd =
>>     object (self : #public)
>>     <public_methods>
>>     <protected_methods>
>>   end
>>   let make_public () -> (new protected :> public)
>>end
>>
>>If this a working alternative, I would prefer over both the 
>>protector type and the protected keyword: clean, simple, and 
>>idiomatic.
> 
> 
> This is both sensible and viable.
> The only weakness is that you won't be able to inherit from the public
> version of your class, since it is not a class but only a type.
> If you need to inherit, you should also export the protected version,
> and make sure that all your constructors apply a similar coercion to
> hide protected methods.

This is really all I need. At present, I do not perceive any 
problem with inheritance, but then again, I might in the 
future. At any rate, this is how I plan to modify the code I 
am presently working on, so as to guarantee that the methods 
I do not wish my object to export be kept private.

> This inheritance problem is the only reason I didn't suggest this
> approach first, but it is certainly simpler.
> 
> Jacques Garrigue

Thank you very much for you interesting comments. I hope 
that discussing such issues as this on the list might help 
the Caml team improve its compiler and language.

Alex Baretta

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

Re: [Caml-list] Protected methods

[Alessandro Baretta]

Jacques Garrigue wrote:
> From: Alessandro Baretta <alex@baretta.com>
> 
>>How about the following pseudocode? Is it sensible/viable?
>>
>>let module M : sig
>>   class type public = object <public_methods> end
>>   val make_public : unit -> public
>>end = struct
>>   class type public = object <public_methods> end
>>   class protectd =
>>     object (self : #public)
>>     <public_methods>
>>     <protected_methods>
>>   end
>>   let make_public () -> (new protected :> public)
>>end
> 
> 
> Actually, after a more thorough look at your code, I'm not sure of
> what you're trying to achieve with it.  Applied directly, it seems
> that it would give you no more than private methods: you can not use
> them outside of the class.

Allowing different instances of a class to invoke protected 
methods on each other, without these methods being exported 
to the general public.

> And I've found a better idiom, that should do about anything you want.

Success! :-)

> module M : sig
>   type hidden
>   class type public = object < public methods >  method full : hidden end
>   val make_public : unit -> public
>   class virtual protected : object ('a)
>     < public methods >
>     < protected methods >
>     method full : 'a
>   end
> end = struct
>   class protected = object (self)
>     < public methods >
>     < protected methods >
>     method full = self
>   end
>   type hidden = protected
>   class type public = object < public methods >  method full : hidden end
>   let make_public () = (new protected : protected :> public)
> end

I publicly bow to another Jedi camler. May inheritance and 
subtyping be with you.

Alex

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

Re: [Caml-list] Protected methods

[Dmitry Bely]

Alessandro Baretta <alex@baretta.com> writes:

> I'm trying to get the semantics of protected methods of C++. I have a
> class with a method that is not meaningful for the outside world, but
> different instances of this class should be able to invoke this method
> on one another.
>
> I need something like the following pseudocode:
>
> class a =
> object
>    method protected m = ...
>    method m2 (obj:a) = a # m
> end

Do not private Ocaml methods have in fact "protected" C++ semantics? They
cannot be called directly but can be used in methods of inherited
classes...

- Dmitry Bely


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

Re: [Caml-list] Protected methods

[Brian Smith]

Dmitry Bely wrote:
 > Do not private Ocaml methods have in fact "protected" C++ semantics?
 > They cannot be called directly but can be used in methods of inherited
 > classes...

This was my impression as well. I think it would be a good idea to add
something to the FAQ about how UML-ish/Java-ish
private/protected/public/package visibility maps to O'Caml. And, if
there isn't a direct mapping in some cases, then perhaps explanations of
"workarounds" like the ones presented in this thread.

Thanks,
Brian



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

Re: [Caml-list] Protected methods

[Alessandro Baretta]

Dmitry Bely wrote:
> Do not private Ocaml methods have in fact "protected" C++ semantics? They
> cannot be called directly but can be used in methods of inherited
> classes...
> 
> - Dmitry Bely

I thought so, too. I made several atttempts, and the 
compiler seemed to reject all of them. Let me see if I can 
cook up a quick example.

# class a = object method private m : unit = (new a) # m end;;
The expression "new a" has type a = <  > but is used with type
   < m : unit; .. >
Only the second object type has a method m

Alex

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

Re: [Caml-list] Protected methods

[Dmitry Bely]

Alessandro Baretta <alex@baretta.com> writes:

>> Do not private Ocaml methods have in fact "protected" C++ semantics? They
>> cannot be called directly but can be used in methods of inherited
>> classes...
>> - Dmitry Bely
>
> I thought so, too. I made several atttempts, and the compiler seemed
> to reject all of them. Let me see if I can cook up a quick example.
>
> # class a = object method private m : unit = (new a) # m end;;
> The expression "new a" has type a = <  > but is used with type
>    < m : unit; .. >
> Only the second object type has a method m

That's because Ocaml private methods can only be applied to the "self" or
"super" object, not to other class instances. Obviously, an object
hierarchy has nothing to do with a class hierarchy (C++'s "private" and
"protected" just ignore existence of the first one, and IMHO that is not
good). But why do you need to call other instance's private/protected
methods? Maybe you should slightly change your design? Could you roughly
describe your task?

- Dmitry Bely


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

Re: [Caml-list] Protected methods

[Alessandro Baretta]

Dmitry Bely wrote:
> Alessandro Baretta <alex@baretta.com> writes:
> 
> But why do you need to call other instance's private/protected
> methods? Maybe you should slightly change your design? Could you roughly
> describe your task?
> 
> - Dmitry Bely

Yes. I have a class whose instances are responsible for 
formatting specific XML trees. Each instance is responsible 
for generating a text box which is decomposed in a header, a 
body, and a footer. While a given object handles directly 
the body of a text box, it delegates the header and the 
footer to two other instances of the same class, in a 
"has-a" relation with the former. This decomposition can be 
done recursively, thereby yielding an object tree or 
hierarchy. There are methods that are only meaningful when 
called by the body object on the header and footer objects. 
Client classes of this text box class are not supposed to 
invoke those methods that are used for data exchange between 
two objects associated by the above "has-a" relation.

Alex

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

OCaml's OO design Re: [Caml-list] Protected methods

[Jacques Garrigue]

From: Brian Smith <brian-l-smith@uiowa.edu>
> Dmitry Bely wrote:
>  > Do not private Ocaml methods have in fact "protected" C++ semantics?
>  > They cannot be called directly but can be used in methods of inherited
>  > classes...
> 
> This was my impression as well. I think it would be a good idea to add
> something to the FAQ about how UML-ish/Java-ish
> private/protected/public/package visibility maps to O'Caml. And, if
> there isn't a direct mapping in some cases, then perhaps explanations of
> "workarounds" like the ones presented in this thread.

That would be certainly useful.
Unfortunately, my understanding of these issues is only partial, as
for most developpers of ocaml: they are much better at type theory of
O.O. than the quirks of each O.O. language.

OK, let's try:
Java                            OCaml
private                         private + hidden by interface
protected/subclasses only       private
default=package protected       public + type abstraction
protected                       public + type abstraction + export class
public                          public

Hidden by interface means defining a class type with some private
methods omitted.
Type abstraction means the workaround I presented earlier in this
thread, combining subtyping to hide methods, and use of an abstract
type to access hidden methods. You can choose to export or not the
class, to allow subclassing outside of the module.
However, if you want to enforce package protection for individual
methods while exporting the class, you have to abstract the type of
the method itself (Gerd Stolpmann's trick is not enough to avoid
redefinition):
        type hidden = ...
        method m : m_hidden

Why is ocaml's typing so different from other typed OO languages?
Essentially, this is because it chose a radically different
theoretical fundation, with structural rather than by-name typing.
This means that unrelated classes may have the same class type!
I believe this choice comes from another, more primitive choice, of
building object-polymoprhism on parametric polymorphism rather than
subtyping.

This provides for a very powerful language (at least in theory), where
you can type safely more OO programs and idioms than in any other
"usable" language.  But this also means some rough edges, as the basis
is rather experimental.

By the way, my experience with ocaml makes me think that the current
design is at least wrong on one point: mixing classes and class types.
As written above, two unrelated classes may have the same class type,
so there is no point in creating a class type for each class (it is
not "owned" by the class).
And a bad consequence of this choice is all these "unbound type
variable" errors, which are just due to the need to define a class
type.
By separating the two, and making classes first-class, one could clean
up some things, and for instance allow defining a class anywhere in an
expression (you would want to do a bit of lambda-lifting for
efficiency).

On the other hand, I also understand why it was designed that way:
abbreviating types is essential to get understandable error messages,
and this would have to be done explicitely, which some might find
verbose.
Yet, I wonder whether the separation would be a worthwhile (extensive)
change.

Cheers,

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

Re: OCaml's OO design Re: [Caml-list] Protected methods

[John Prevost]

Just as a note, I think the major barrier to the "friend" behavior of
"protected" and "private" in Java (that is, methods of the appropriate
classes are able to call a given method even though other pieces of
code cannot see that it exists) is that subtyping and subclassing are
independent.

In Java, if you are handed a value of a given type and know that type
is a subclass of the "Foo" class, you *know* that it has all the
methods (hidden and not hidden) that a Foo has.  In O'Caml, this
luxury is not available.  If the object type of foo does not indicate
that a method "bar" exists, it may very well not exist.

This is why you need to do a song and dance with abstract types to
achieve the same effect.  The method *must* be visible or other
objects can't call it, since it is *only* the type of an object that
defines its interface.  Using type abstraction means that only code
that knows the underlying type has access, which allows you to show
that the method is there and has the right type, while not allowing
access to everybody.

Does this feel clunky?  Yes, a little bit.  But it's a price I'm
willing to pay for structural subtyping and self types.  I think it
calls to mind some of the subtler problems with subclassing and
subtyping--like invariants.  If you call a "protected" method in Java,
it generally means you're depending on the subclass to maintain
invariants from the superclass.  But all too often, this can lead to
problems where modularity breaks down.

Bondage programming?  Yeah, could be.  :) But it has some interesting
typing properties rarely found elsewhere, and makes us think about a
different set of implications in object calculi than most languages.
Consider learning to work within these constraints to be working in a
different programming paradigm than Java or C++ provides--because it
clearly is.  Different idioms are needed.  Some possibilities that
were closed off become open, and some that were open are now more
constrained.

It's, quite honestly, a load of fun.

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