Re: Multiple Inheritance / Generated Hidden Code

--Apple-Mail=_65EB4D13-878C-4539-ACBD-1238A8039002
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

You could:

1) write a static analysis tool; or
2) use Pragmas as a tool to add/check methods and protocol adherence; or
3) use an alternative Compiler for your classes.  See implementors of =
#compilerClass for lots of examples.  Load SiouX to see an example of =
classes that use a =E2=80=9CJavascriptCompiler=E2=80=9D rather than the =
Smalltalk Compiler.

None of these solutions replace MI and given that you=E2=80=99ll have to =
code them and maintain them, you might not consider it worth the effort. =
 I=E2=80=99ve never had a case where I needed this in Smalltalk.  I do a =
lot of TDD to avoid static analysis and use delegation to handle most of =
the cases where someone might use MI or =E2=80=9CTraits.=E2=80=9D  I've =
used Python extensively over the years and see the benefits of MI when I =
look at how the professionals use it but I cut my OO teeth in Smalltalk =
and Java so I=E2=80=99ve learned to live (well) without it.

If you go the static analysis route, all of the information you need =
about classes is contained in the class.  See the hierarchy of the class =
Class.  It can be a pain to find what you want b/c there are a ton of =
methods there.  But, just as an example, here are all classes reachable =
from the Smalltalk namespace that have the method category #copying:

allCopying :=3D Smalltalk allClasses select: [:e | e organization =
categories includes: #copying].

Here is the source code to the method #postCopy in the first class in =
the list above:

(allCopying first compiledMethodAt: #postCopy) asSourceCodeDocument

There=E2=80=99s probably a better choice than =
#asSourceCodeDocument=E2=80=A6something that just fetches the source =
string, but I didn=E2=80=99t want to hunt around for it.  Just inspect =
(allCopying first compiledMethodAt: #postCopy) and browse the =
corresponding class (CompiledMethod?) to see what you can do with it. =20=


As far as code generation goes, look at senders of the various =
#compile:* methods in the hierarchy of the class Class to see how you =
can generate methods.  I think most of the compilation related stuff is =
in ClassDescription which is an ancestor of Class.  I don=E2=80=99t =
recommend generating hidden code.  In fact, I=E2=80=99d never use a =
system that did that.  Personal preference, of course.

I don=E2=80=99t personally use method categories as strict method =
protocols.  If I needed something like this from a software engineering =
standpoint I=E2=80=99d probably use pragmas (see class Pragma and the =
corresponding documentation in one of the PDF=E2=80=99s in the doc =
directory) and try to do something fancy with the compiler.  It =
certainly isn=E2=80=99t a substitute for MI but if you=E2=80=99re =
committed to VisualWorks you could probably meet your project=E2=80=99s =
needs with a modest investment developing tools.

Best,

David

> On Aug 13, 2025, at 4:57=E2=80=AFAM, andre <[email protected]> =
wrote:
>=20
> Are there any existing solutions to multiple-inheritance?=20
>=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
>=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.
>=20
> Multiple-inheritance would be a step towards a more modular and =
maintainable code base.
>=20
> 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
>=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.
>=20
> Obviously this is more involved than a weekend project. Has anyone =
already tried this?
>=20
> Andre
>=20


--Apple-Mail=_65EB4D13-878C-4539-ACBD-1238A8039002
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><div>You =
could:</div><div><br></div><div>1) write a static analysis tool; =
or</div><div>2) use Pragmas as a tool to add/check methods and protocol =
adherence; or</div><div>3) use an alternative Compiler for your classes. =
&nbsp;See implementors of #compilerClass for lots of examples. =
&nbsp;Load SiouX to see an example of classes that use a =
=E2=80=9CJavascriptCompiler=E2=80=9D rather than the Smalltalk =
Compiler.</div><div><br></div><div>None of these solutions replace MI =
and given that you=E2=80=99ll have to code them and maintain them, you =
might not consider it worth the effort. &nbsp;I=E2=80=99ve never had a =
case where I needed this in Smalltalk. &nbsp;I do a lot of TDD to avoid =
static analysis and use delegation to handle most of the cases where =
someone might use MI or =E2=80=9CTraits.=E2=80=9D &nbsp;I've used Python =
extensively over the years and see the benefits of MI when I look at how =
the professionals use it but I cut my OO teeth in Smalltalk and Java so =
I=E2=80=99ve learned to live (well) without it.</div><div><br></div>If =
you go the static analysis route, all of the information you need about =
classes is contained in the class. &nbsp;See the&nbsp;<span =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">hierarchy of =
the&nbsp;</span>class Class. &nbsp;It can be a pain to find what you =
want b/c there are a ton of methods there. &nbsp;But, just as an =
example, here are all classes reachable from the Smalltalk namespace =
that have the method category #copying:<div><br></div><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: =
0px;"><div>allCopying :=3D Smalltalk allClasses select: [:e | e =
organization categories includes: =
#copying].</div></blockquote><div><br></div><div>Here is the source code =
to the method #postCopy in the first class in the list =
above:</div><div><br></div><blockquote style=3D"margin: 0 0 0 40px; =
border: none; padding: 0px;"><div>(allCopying first compiledMethodAt: =
#postCopy) =
asSourceCodeDocument</div></blockquote><div><div><br></div><div>There=E2=80=
=99s probably a better choice than #asSourceCodeDocument=E2=80=A6something=
 that just fetches the source string, but I didn=E2=80=99t want to hunt =
around for it. &nbsp;Just inspect&nbsp;<font color=3D"#000000">(allCopying=
 first compiledMethodAt: #postCopy) and browse the corresponding class =
(CompiledMethod?) to see what you can do with it. =
&nbsp;</font></div><div><br></div><div>As far as code generation goes, =
look at senders of the various #compile:* methods in the hierarchy of =
the class Class to see how you can generate methods. &nbsp;I think most =
of the compilation related stuff is in ClassDescription which is an =
ancestor of Class. &nbsp;I don=E2=80=99t recommend generating hidden =
code. &nbsp;In fact, I=E2=80=99d never use a system that did that. =
&nbsp;Personal preference, of course.</div><div><br></div><div>I don=E2=80=
=99t personally use method categories as strict method protocols. =
&nbsp;If I needed something like this from a software engineering =
standpoint I=E2=80=99d probably use pragmas (see class Pragma and the =
corresponding documentation in one of the PDF=E2=80=99s in the doc =
directory) and try to do something fancy with the compiler. &nbsp;It =
certainly isn=E2=80=99t a substitute for MI but if you=E2=80=99re =
committed to VisualWorks you could probably meet your project=E2=80=99s =
needs with a modest investment developing =
tools.</div><div><br></div><div>Best,</div><div><br></div><div>David</div>=
<div><br><blockquote type=3D"cite"><div>On Aug 13, 2025, at 4:57=E2=80=AFA=
M, andre &lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>Are there any existing =
solutions to multiple-inheritance? <br><br>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. =
<br><br>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.<br><br>Multiple-inheritance would be a step towards a more modular =
and maintainable code base.<br><br>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. <br><br>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.<br><br>Obviously this is more involved than a =
weekend project. Has anyone already tried =
this?<br><br>Andre<br><br></div></div></blockquote></div><br></div></body>=
</html>=

--Apple-Mail=_65EB4D13-878C-4539-ACBD-1238A8039002--