Multiple Inheritance / Generated Hidden Code

andre <[email protected]> Wed, 13 Aug 2025 10:57:56 +0200
Newsgroups gmane.comp.lang.smalltalk.vwnc
Message-ID <[email protected]>
Are there any existing solutions to multiple-inheritance?=20

For deep and UIs and complex resource management, single-inheritance =
turned out to be painfully limiting. I happen to waste a lot of time =
(days, weeks) browsing senders and implementors to check protocols (the =
closest thing to "interface") for correctness and conciseness across =
multiple class hierarchies. There's no way to supply protocols with =
state and (default) behavior.=20

Inconsistencies are not detected at compile time. Maintaining =
correctness manually is a very costly burden. Much of the producivity =
advantage of Smalltalk is ruined this way. With thousands of classes =
it's almost impossible to be sure that everything was accounted for.

Multiple-inheritance would be a step towards a more modular and =
maintainable code base.

Instead of using #doesNotUnderstand: and message delegation at runtime =
(slow), there's the possibility of deploying copies of inherited =
methods, plus any code that deals with casting and conflict resolution, =
at compile time. Generated code could be tagged with pragmas to hide it =
from the system browser, exclude it from Store, etc.=20

I believe there is huge potential in generated hidden code. This =
technique could be leveraged to implement many useful idioms that =
Smalltalk doesn't support out of the box without sacrificing runtime =
performance.

Obviously this is more involved than a weekend project. Has anyone =
already tried this?

Andre