[Caml-list] Objects and private methods

[Caml-list] Objects and private methods

[Patrick M Doane]

I'm having some trouble getting the following type of structure to
type-check:

  class type a = object method get_b : a end

         and b = object method b : unit end

  class a_impl =
  (object (self)
    method get_b = (self :> b)
    method private b = ()
  end : a)
  ;;

This produces the error message:

  The class type object method b : unit method get_b : b end
  is not matched by the class type a
  The public method b cannot be hidden

The basic idea is that the class 'a_impl' implements 'b' privately. This
seems like something that should be possible to do.  I suspect that the
coercion of self to 'b' is causing the problem here.

I would have expected the failure to occur when coercing to type 'b' as
the method is declared private (which does not match the signature).

Any thoughts?

Thanks,
Patrick

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Objects and private methods

[Jacques Garrigue]

> I'm having some trouble getting the following type of structure to
> type-check:
> 
>   class type a = object method get_b : a end
> 
>          and b = object method b : unit end
> 
>   class a_impl =
>   (object (self)
>     method get_b = (self :> b)
>     method private b = ()
>   end : a)
>   ;;
> 
> This produces the error message:
> 
>   The class type object method b : unit method get_b : b end
>   is not matched by the class type a
>   The public method b cannot be hidden
> 
> I would have expected the failure to occur when coercing to type 'b' as
> the method is declared private (which does not match the signature).

Due to the way privacy attributes are implemented in the type checker,
a type annotation can force a private method to become public (but
never the opposite). You can see it on the following example.

  # class c = object (self : < b : 'a; .. >) method private b = 1 end;;
  class c : object method b : int end

This explains why the type checker doesn't complain about b not being
public: it makes it public as needed. And since b is public, you
cannot hide it.
(This may seem strange from the point of view of privacy, but you
should just understand private methods as "may be hidden in a
subclass"; if unified with a public method it may no longe be hidden.)

> The basic idea is that the class 'a_impl' implements 'b' privately. This
> seems like something that should be possible to do.  I suspect that the
> coercion of self to 'b' is causing the problem here.

I don't understand very well what you mean by "implement privately":
a and b do not seem to be related in your code.
I will suppose that you meant
  class type a = object method get_b : b end

You cannot convert something from private to public through a coercion
(this is different from forcing it with an annotation). This is
because the values are actually different: a private method and a
public method have different internal representations.
On the other hand, you can hide a method through coercions.

  class a_impl = object (self)
    method get_b = (self :> b)
    method b = ()
  end
  let new_a = (new a_impl :> a)

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Objects and private methods

[Patrick M Doane]

Hello, thanks for the quick reply.

On Fri, 21 Dec 2001, Jacques Garrigue wrote:

> > I'm having some trouble getting the following type of structure to
> > type-check:
> >
> >   class type a = object method get_b : a end
> >
> >          and b = object method b : unit end
> >
> >   class a_impl =
> >   (object (self)
> >     method get_b = (self :> b)
> >     method private b = ()
> >   end : a)
> >   ;;
> >
>
> Due to the way privacy attributes are implemented in the type checker,
> a type annotation can force a private method to become public (but
> never the opposite). You can see it on the following example.
>
>   # class c = object (self : < b : 'a; .. >) method private b = 1 end;;
>   class c : object method b : int end
>
> This explains why the type checker doesn't complain about b not being
> public: it makes it public as needed. And since b is public, you
> cannot hide it.
> (This may seem strange from the point of view of privacy, but you
> should just understand private methods as "may be hidden in a
> subclass"; if unified with a public method it may no longe be hidden.)

Okay - and in this case the signature matching constraint is considered a
subclass?

> > The basic idea is that the class 'a_impl' implements 'b' privately. This
> > seems like something that should be possible to do.  I suspect that the
> > coercion of self to 'b' is causing the problem here.
>
> I don't understand very well what you mean by "implement privately":
> a and b do not seem to be related in your code.
> I will suppose that you meant
>   class type a = object method get_b : b end

Yes, that's right. I was distilling from a larger example and missed that.

> You cannot convert something from private to public through a coercion
> (this is different from forcing it with an annotation). This is
> because the values are actually different: a private method and a
> public method have different internal representations.

Are there any papers that I could read over that would give a better sense
for the internal representations? That might help me understand some of
these limitations better.

> On the other hand, you can hide a method through coercions.
>
>   class a_impl = object (self)
>     method get_b = (self :> b)
>     method b = ()
>   end
>   let new_a = (new a_impl :> a)

Thanks! What then are the advantages to using an annotation instead of a
coercion for signature matching? For example, with a hypothetical syntax
like this:

class a_impl :> a = object (self)
  method get_b = (self :> b)
  method b = ()
end

Patrick

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Objects and private methods

[Jacques Garrigue]

From: Patrick M Doane <patrick@watson.org>

> > You cannot convert something from private to public through a coercion
> > (this is different from forcing it with an annotation). This is
> > because the values are actually different: a private method and a
> > public method have different internal representations.
> 
> Are there any papers that I could read over that would give a better sense
> for the internal representations? That might help me understand some of
> these limitations better.

I don't think so, but books like Abadi&Cardelli's Types for Objects
would give you an insight on what is safe and what is not.

> > On the other hand, you can hide a method through coercions.
> >
> >   class a_impl = object (self)
> >     method get_b = (self :> b)
> >     method b = ()
> >   end
> >   let new_a = (new a_impl :> a)
> 
> Thanks! What then are the advantages to using an annotation instead of a
> coercion for signature matching? For example, with a hypothetical syntax
> like this:
> 
> class a_impl :> a = object (self)
>   method get_b = (self :> b)
>   method b = ()
> end

You can only coerce from type to type, not from signature to
signature. Otherwise you would be able to hide a method, and then
redefine it with the same name but another type. Such inheritance
patterns are not type safe, so you are not allowed to hide a public
method at the class level, only at the expression level, where it is
safe.

Jacques Garrigue
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr