4 ms·
A lot of these sorts of language features feel to me like workarounds for a lack of methods with multiple dispatch: methods like the transfer method seem to bel
by fiddlerwoaroof 4y ago
A lot of these sorts of language features feel to me like workarounds for a lack of methods with multiple dispatch: methods like the transfer method seem to belong to a collection of classes but typical OO languages force you to pick a single class to attach them to.
- ohgodplsno 4y agoNothing's stopping you from making a Transferable interface. Everything that implements it has to implement transfer(), and you can then make an extension function on Transferable instead of your implementation. Additionally, multiple dispatch in JVM languages (except Groovy because it implements multiple dispatch already) can just be done by having two layers of classes. Yes, it's a holdover from the JVM being heavily class based, but nothing preventing you from doing that. Hell, define both your classes, and put all your logic in a single file with extension functions. Kotlin is quite free form when it comes to where you should put your things, what it should be attached to, etc.
- pjmlp 4y agoClojure also has it via its simplified CLOS implementation.
- artemonster 4y agoThere is a difference between multidisptach (all/some arguments decide what is being applied) or contextual dispatch, where dynamic scope decides that.