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

only methods are used where multies should be, preventing dispatch to Mu.* candidates #6102

Open
p6rt opened this issue Feb 26, 2017 · 4 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Feb 26, 2017

Migrated from rt.perl.org#130867 (status was 'new')

Searchable as RT130867$

@p6rt
Copy link
Author

p6rt commented Feb 26, 2017

From @zoffixznet

Some types provide methods, like .Bool, .elems, .Str that are defined for :D subtypes. However,
these methods are defined as `only` methods, not `multi`, so the dispatch for :U subtypes fails,
instead of those be handled by Mu.* methods.

I already fixed[^1] a bunch for Baggy role, but I notice other types have similar issue​:

  <Zoffix> m​: Seq.Bool
  <camelia> rakudo-moar dd4dfb​: OUTPUT​: «Invocant requires an instance of type Seq, but a type object was passed. Did you forget a .new?␤ in block <unit> at <tmp> line 1␤␤»

We need to check the codebase for more of these. I think some construct similar to `for Any.^methods(​:all)».name -> $name { for @​all-core-types { ."$name"() }}`
can be used for automated finding of methods that need to be changed to multies.

[1] rakudo/rakudo@e8af855

@p6rt
Copy link
Author

p6rt commented Mar 15, 2017

From @zoffixznet

Another piece-meal fix​: for Bool​:U.Str​:
rakudo/rakudo@3de5fb24c9
Raku/roast@de5f00b909

1 similar comment
@p6rt
Copy link
Author

p6rt commented Mar 15, 2017

From @zoffixznet

Another piece-meal fix​: for Bool​:U.Str​:
rakudo/rakudo@3de5fb24c9
Raku/roast@de5f00b909

@p6rt
Copy link
Author

p6rt commented Feb 23, 2018

From @zoffixznet

Seq.Int, Seq.Numeric, Seq.elems are another bunch.

We need some programmatically-assisted way to audit the entire codebase for these.

@p6rt p6rt added the Bug label Jan 5, 2020
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