No need for language support for your "typeunion" suggestion (though really, it's more generic than that), and of course you can do the same as in my example just with "when String,Integer"; the only thing this buys you is the ability to pass the list around as an object:
classTypeUniondefinitialize(*args)@types=argsenddef===(arg)@types.detect{|t|t===arg}endenddeftypeunion(*args)returnTypeUnion.new(*args)enddeftest(arg)caseargwhentypeunion(String,Integer)puts"String or Integer: #{arg}"elseputs"What's this? #{arg.inspect}"endendtest(4)test("foo")test(1.0)test(false)
As for your suggestion for multiple dispatch, I don't think it's a hard change at all. I'm working on a Ruby compiler, and the way I'd implement something like that would simply be to create hidden methods with the type signature for rewrites at call-sites where I can prove the types at compile time, and make the "plain" method a generated method that does the type checks and dispatches to each implementation. Conceptually it's really just wrapping every variant in a big "case", and not hard at all.
The hard part is getting people to agree to add it.
Thanks for giving a proper name for what I'm looking for. Neither pattern matching nor method overload mentioned above did not seem correct. Multiple dispatch clicks.
Perhaps you're right that it soudn't be so hard to implement. But wouldn't it break backwards compatibility somehow? Ruby core team is known for keeping it at all costs.
It would break semantics if overloads are allowed in a way that is syntactically valid in older code. So the challenge would be to pick syntax to specify the type signatures that can not occur in old working code.
Finding syntax that doesn't look awful but that is currently invalid would actually likely be the hardest part of adding support for it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
No need for language support for your "typeunion" suggestion (though really, it's more generic than that), and of course you can do the same as in my example just with "when String,Integer"; the only thing this buys you is the ability to pass the list around as an object:
As for your suggestion for multiple dispatch, I don't think it's a hard change at all. I'm working on a Ruby compiler, and the way I'd implement something like that would simply be to create hidden methods with the type signature for rewrites at call-sites where I can prove the types at compile time, and make the "plain" method a generated method that does the type checks and dispatches to each implementation. Conceptually it's really just wrapping every variant in a big "case", and not hard at all.
The hard part is getting people to agree to add it.
Thanks for giving a proper name for what I'm looking for. Neither pattern matching nor method overload mentioned above did not seem correct. Multiple dispatch clicks.
Perhaps you're right that it soudn't be so hard to implement. But wouldn't it break backwards compatibility somehow? Ruby core team is known for keeping it at all costs.
It would break semantics if overloads are allowed in a way that is syntactically valid in older code. So the challenge would be to pick syntax to specify the type signatures that can not occur in old working code.
Finding syntax that doesn't look awful but that is currently invalid would actually likely be the hardest part of adding support for it.