Re: Multiple Inheritance / Generated Hidden Code

Andre:

You are trying to do static analysis. But Smalltalk is  built to be dynamic.=
 So run the program constantly and discover using the debugger. You should b=
e in the debugger more than fifty percent of the time. You can edit and run w=
ithout shutting the debugger or program. That is the paradigm shift.=20

All the best,
Aik-Siong Koh

> On Aug 13, 2025, at 2:58=E2=80=AFAM, andre <[email protected]> wro=
te:
>=20
> =EF=BB=BFAre there any existing solutions to multiple-inheritance?
>=20
> For deep and UIs and complex resource management, single-inheritance turne=
d 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 hierarch=
ies. There's no way to supply protocols with state and (default) behavior.
>=20
> Inconsistencies are not detected at compile time. Maintaining correctness m=
anually is a very costly burden. Much of the producivity advantage of Smallt=
alk is ruined this way. With thousands of classes it's almost impossible to b=
e sure that everything was accounted for.
>=20
> Multiple-inheritance would be a step towards a more modular and maintainab=
le code base.
>=20
> Instead of using #doesNotUnderstand: and message delegation at runtime (sl=
ow), there's the possibility of deploying copies of inherited methods, plus a=
ny code that deals with casting and conflict resolution, at compile time. Ge=
nerated 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 s=
upport out of the box without sacrificing runtime performance.
>=20
> Obviously this is more involved than a weekend project. Has anyone already=
 tried this?
>=20
> Andre
>=20
>=20