But this solution needs to write down the type(struct) of every parameter. I think the biggest reason why dynamic language is popular is they don't force users to write type every time. So this is contradicting to the charm of dynamic language(as literally, all scripting language is dynamic, including wren).
We can mark those function which doesn't specify all the types as default, but it will make code very ambiguous, like:
function add(A a, B b)
function add(A a, b)
function add(a, B b)
function add(a, b)
You only need to specify the type if you want to dispatch on the type. In CL, unannotated arguments are considered to be of type T, which indicates they could have any value.
This isn’t any different from the way methods are dispatched in Wren or Python or anything: it’s just that the type of the single argument that’s relevant for dispatch (this/self/etc.) is the class. But, the disadvantage is that since methods are nested in the class definition, there’s no clean way to extend pre-existing classes without modifying the source of the defining class. If “method” is its own concept, on equal footing with classes, you can put all the base cases together and then users that want to extend the set of types the operation works on can specify additional cases to define the interaction between their new types and the pre-existing ones.
I’ve written a lot of Common Lisp now, and I’ve found that multimethods help eliminate a lot of boilerplate where you write classes that wrap an existing class and delegate to it and similar patterns.
We can mark those function which doesn't specify all the types as default, but it will make code very ambiguous, like:
function add(A a, B b) function add(A a, b) function add(a, B b) function add(a, b)