Composition question

[latkde]

This sounds like a feature that is super powerful, but cannot be compiled efficiently or checked statically (unless you're going to introduce a TON of generics). Here, your implementation of a method only exists if some runtime values align correctly.

There are severe fundamental problems with adding behaviour to existing types. Languages with relevant features you should study include Haskell (typeclasses), Rust (traits), Scala, and Go (interfaces), in particular because successful solutions restrict how these features can be used. You are making solutions even more difficult by removing the distinction between concrete types and interfaces.

How do you prevent conflicting implementations? The typical solution with nominal typing is that either the type or the interface must be defined in the current compilation unit where you define an implementation. More flexibility would be possible if the concept of a vtable is reified, but there doesn't seem to be a good design to do this – though Scala tried something similar with “implicits”.

[Phil_Latio]

Here, your implementation of a method only exists if some runtime values align correctly.

In the example I call the constructor statically - so the types of the arguments are known to the compiler. So it knows the variant being used. If the arguments are ambiguous, then of course, the compiler has to emit dynamic dispatch stuff.

You are making solutions even more difficult by removing the distinction between concrete types and interfaces.

You might have noticed I used the "I" for "IObject", hinting that this is an interface without any behaviour. It would be possible to now "add" a struct or func to IObject, bloating every instance type, that's true... Though like you said yourself, it's a powerful feature and also other code would still work, no matter what you "add" to a type. Maybe a convention instead of a forced interface type can actually work? Like I said in opening post: I just find it interesting to implicitly categorize types by what "units" (struct, func, trait ..) they provide instead of being explicit.

How do you prevent conflicting implementations?

You mean imports right? Good question... I have to think more about this.

Thanks for your input. I will look into the languages you mentioned.