Proposal: making `Class` and `Module` classes generic -- `Class[I]` and `Module[I]` about rbs HOT 9 OPEN

Class[String] cannot be equivalent to singleton(String), because singleton(String) has singleton methods.

I'm not sure if adding a generic parameter to Class makes sense, because it can only be used to allocate method. (RBS generates new for each classes with types.)

I'm curious if there are more use cases.

from rbs.

Class[String] cannot be equivalent to singleton(String), because singleton(String) has singleton methods.

You are correct, the singleton(String) syntax enables special handling of singleton methods on the String class.
But also note that, anything can have singleton methods, not just classes (Class instances). And unfortunately, there is no RBS equivalent for:

class << SINGLETON = Superclass.new
  def my_singleton_method …

and the current workaround is:

SINGLETON: Superclass & _SINGLETON
interface _SINGLETON
  def my_singleton_method …

I'm not sure if adding a generic parameter to Class makes sense, because it can only be used to allocate method. (RBS generates new for each classes with types.)

I'm curious if there are more use cases.

class Class[I]
  # The attached objects of singleton classes is the only “instance” they can have,
  # vs. regular classes that have `#allocate`/`#new`
  def attached_object: () -> I
  # This is `[T < I] (Class[T]) -> void` with the ineffective `[T]` flattened.
  def inherited: (Class[I]) -> void
  # ditto
  def subclasses: () -> Array[Class[I]]
  # If RBS has explicit countervariance like Java does…
  def superclass: [I < T] () -> Class[T]
end

The top post also includes an abstraction of a user use case. Here’s my use case unabstracted.

from rbs.

If I may jump in, but i'd consider reserving that syntax to solve either module mixins, or delegation, both of which aren't yet solved in rbs.

module A[B]
  # A mixin of B, meaning methods of A can call functions defined in B

# or

class A[B]
  # class a delegates methods to B, could also solve the "delegate" stdlib

from rbs.

If I may jump in

of coarse you may

but i'd consider reserving that syntax to solve either module mixins, or delegation, both of which aren't yet solved in rbs.

module A[B]
  # A mixin of B, meaning methods of A can call functions defined in B

# or

class A[B]
  # class a delegates methods to B, could also solve the "delegate" stdlib

Let type variables go wild and do crazy things –

module A[B]
  include B
  …

from rbs.