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