Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Wish: class types that constrain #3323

Closed
vicuna opened this issue May 1, 2002 · 2 comments
Closed

Feature Wish: class types that constrain #3323

vicuna opened this issue May 1, 2002 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented May 1, 2002

Original bug ID: 1132
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: chris quinn
Version: 3.04
OS:
Submission from: 212.42.169.63 (212.42.169.63)

Why is it that a class type is not analogous to signatures by being applicable
to a class containing extra methods which require hiding?

class type t = object end

class ic = object
method x = 0
end

class t' arg1 arg2 : t = object
inherit ic
end

The compiler complains that method x cannot be hidden.
Note the presence of arguments to class t' - I want to define functions
in terms of a class type free of types of arguments used in construction.
Therefore I must specify an explicit class type, in this case t.
And the only way I can find to accommodate the compiler is
to declare in t' :
method private x = x

Yuk! Why should I need to do this? Is it not redundant?
In my situation I have a lot of classes inheriting class ic and whenever I add a
method to it I must revisit them all and add the above line!

So it would be nice if class types could constrain but I half suspect there is
good reason this is not the case!

Thanks.

@vicuna
Copy link
Author

vicuna commented May 1, 2002

Comment author: administrator

Full_Name: chris quinn

Why is it that a class type is not analogous to signatures by being
applicable to a class containing extra methods which require hiding?

class type t = object end

class ic = object
method x = 0
end

class t' arg1 arg2 : t = object
inherit ic
end

The compiler complains that method x cannot be hidden.

IIRC, the reason is two-fold.
A first reason is a consequence of a difference in the way public and
private methods are called.
For public methods, they are searched by name in the method table
(it's more efficient than that, but this is the semantics)

So we could consider the following situation

class c : object method y : float end =
object (self)
method x = 1.0
method = self#x +. 2.0
end

class d = object
inherit c
method x = 1
end

let _ = (new d)#y

Since public methods are looked up by name, self#x becomes 1 rather
than 1.0, and you get a segmentation fault!

The second reason is that the relation required between the interface
and the implementation is not so clear: one could think about allowing
more (with a different implementation), but where to stop? Is full
subtyping OK? Not always.

Note the presence of arguments to class t' - I want to define functions
in terms of a class type free of types of arguments used in construction.
Therefore I must specify an explicit class type, in this case t.
And the only way I can find to accommodate the compiler is
to declare in t' :
method private x = x

Private methods use private labels in place of names, and a different
label is created when a method is hidden. As a result, the two methods
x would have a different label, and self#x would call the first one.
Safe!

There is really nothing wrong in having only private methods, since
you can make them public as soon as needed:

class c : object method x : int end =
object method private x = 0 end

In my situation I have a lot of classes inheriting class ic and
whenever I add a method to it I must revisit them all and add the
above line!

You can define only private methods in your base class, and inherit
them as private or public as you wish.

Jacques

@vicuna
Copy link
Author

vicuna commented May 7, 2002

Comment author: administrator

Hiding public methods is indeed unsound.

@vicuna vicuna closed this as completed May 7, 2002
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant