You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the usage of singleton seems to be limited to the following usages:
# foo accepts the FooClass as argument, or any subclass of it# rb: foo(FooClass)deffoo: (singleton(FooClass))# foo accepts the FooModule module as argument# rb: foo(FooModule)deffoo: (singleton(FooModule))# foo accepts instances of a class with the FooModule mixed in, or with its singleton class extended by it# rb: foo(foo_class_instance)deffoo: (FooModule)
Currently, it seems to not be possible to declare the acceptance of "the class with FooModule mixed in", for functions called with foo(ClassWithFooModule). I've tried declaring. foo: (Object & FooModule), but this is something which the parser does not accept:
In lack of an alternative way to declare it, I guess this makes it a feature request. I think this is a quite common pattern, for instance in background job frameworks, such as sidekiq or shoryuken, where you can call Sidekiq.enqueue(JobClass) or pass it to push_bulk, and the JobClass only has to include the Sidekiq::Job mixin (shoryuken works similarly), or in middleware chains, which usually contain classes as arguments, and in some cases these must include some some module, or "quack" like some interface (usually via implementing call(this, that, other)).
(the latter point points to also supporting this pattern for interfaces, i.e. singleton(Object & _IFoo))
The text was updated successfully, but these errors were encountered:
Currently, the usage of
singleton
seems to be limited to the following usages:Currently, it seems to not be possible to declare the acceptance of "the class with FooModule mixed in", for functions called with
foo(ClassWithFooModule)
. I've tried declaring.foo: (Object & FooModule)
, but this is something which the parser does not accept:In lack of an alternative way to declare it, I guess this makes it a feature request. I think this is a quite common pattern, for instance in background job frameworks, such as sidekiq or shoryuken, where you can call
Sidekiq.enqueue(JobClass)
or pass it to push_bulk, and the JobClass only has to include theSidekiq::Job
mixin (shoryuken works similarly), or in middleware chains, which usually contain classes as arguments, and in some cases these must include some some module, or "quack" like some interface (usually via implementingcall(this, that, other)
).(the latter point points to also supporting this pattern for interfaces, i.e.
singleton(Object & _IFoo)
)The text was updated successfully, but these errors were encountered: