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

Wish: when inheriting from class types, allow to subtype methods #6130

Closed
vicuna opened this issue Aug 13, 2013 · 2 comments
Closed

Wish: when inheriting from class types, allow to subtype methods #6130

vicuna opened this issue Aug 13, 2013 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Aug 13, 2013

Original bug ID: 6130
Reporter: gerd
Status: acknowledged (set by @damiendoligez on 2013-08-19T17:13:31Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.00.1
Category: typing
Monitored by: @lpw25 @hcarty

Bug description

Currently, this does not work:

class type x = object
  method p : [ `P ] -> unit
  (* many more methods *)
end

class type y = object
  inherit x
  method p : [ `P | `Q ] -> unit
end

The suggestion is to allow that method types can be subtypes of the inherited types (maybe requiring method! syntax).

Additional information

This would be extremely helpful, because in some situations there is no easy workaround, especially if the definition of x is not in my own code base.

As classes allow method overriding with subtypes, permitting the same for class types would also be good for the symmetry in the language.

@vicuna
Copy link
Author

vicuna commented Aug 20, 2013

Comment author: @garrigue

This is a long standing request.
There are 3 reasons it was not implemented:

  1. since ocaml allows to use the "type of self", ensuring the soundness of this feature can be tricky.
    (This looks ok, but I think nobody has proved that formally yet)

  2. this requires important changes in the type inference of classes: currently, the typing of inheritance just uses unification, which is not compatible with subtyping

  3. to preserve backward compatibility, all such methods would have to be explicitly annotated, so it would be a bit heavy to use

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant