RE: Multiple Inheritance / Generated Hidden Code
Davide Grandi <[email protected]> Wed, 13 Aug 2025 17:15:29 +0200
| Newsgroups | gmane.comp.lang.smalltalk.vwnc |
|---|---|
| Message-ID | <[email protected]> |
----_com.samsung.android.email_3602253413433640 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi=C2=A0do you have already excluded some inheritance-to-composition refact= oring ?And, for the manual checking of protocol alignment: are the "class m= etadata" (class' selectors list) not enough for automated checks ?Buona gio= rnata / have a nice day,=C2=A0 =C2=A0 Davide Grandi(sent from a mobile devi= ce: excuse brevity and typos)--email: [email protected]: https= ://urldefense.com/v3/__https://linkedin.com/in/davidegrandi__;!!DZ3fjg!9Mmj= qRWDpKwQJj9LcenkKm_KeJMMeA1mXfJCM85y7OPSWfBshRRXB5yRXclNNj_GtOknXq75YrElNLn= tsuMd8nMH$=20 -------- Messaggio originale --------Da: andre <[email protected]> = Data: 13/08/25 10:58 (GMT+01:00) A: [email protected] Oggetto: [vwnc] Mult= iple Inheritance / Generated Hidden Code Are there any existing solutions t= o multiple-inheritance? For deep and UIs and complex resource management, s= ingle-inheritance turned out to be painfully limiting. I happen to waste a = lot of time (days, weeks) browsing senders and implementors to check protoc= ols (the closest thing to "interface") for correctness and conciseness acro= ss multiple class hierarchies. There's no way to supply protocols with stat= e and (default) behavior. Inconsistencies are not detected at compile time.= Maintaining correctness manually is a very costly burden. Much of the prod= ucivity advantage of Smalltalk is ruined this way. With thousands of classe= s it's almost impossible to be sure that everything was accounted for.Multi= ple-inheritance would be a step towards a more modular and maintainable cod= e base.Instead of using #doesNotUnderstand: and message delegation at runti= me (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 syst= em browser, exclude it from Store, etc. I believe there is huge potential i= n generated hidden code. This technique could be leveraged to implement man= y useful idioms that Smalltalk doesn't support out of the box without sacri= ficing runtime performance.Obviously this is more involved than a weekend p= roject. Has anyone already tried this?Andre= ----_com.samsung.android.email_3602253413433640 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset= =3DUTF-8"></head><body dir=3D"auto"><div dir=3D"auto">Hi </div><div di= r=3D"auto">do you have already excluded some inheritance-to-composition ref= actoring ?</div><div dir=3D"auto"><br></div><div dir=3D"auto">And, for the = manual checking of protocol alignment: are the "class metadata" (class' sel= ectors list) not enough for automated checks ?</div><div dir=3D"auto"><br><= /div><div id=3D"composer_signature" dir=3D"auto"><meta http-equiv=3D"Conten= t-Type" content=3D"text/html; charset=3DUTF-8">Buona giornata / have a nice= day,<div dir=3D"auto"><br></div><div dir=3D"auto"> Davide Gra= ndi</div><div dir=3D"auto">(sent from a mobile device: excuse brevity and t= ypos)</div><div dir=3D"auto">--</div><div dir=3D"auto">email: davide.grandi= @email.it</div><div dir=3D"auto">linkedin: <a href=3D"https://urldefense.co= m/v3/__https://linkedin.com/in/davidegrandi__;!!DZ3fjg!9MmjqRWDpKwQJj9Lcenk= Km_KeJMMeA1mXfJCM85y7OPSWfBshRRXB5yRXclNNj_GtOknXq75YrElNLntsuMd8nMH$">http= s://linkedin.com/in/davidegrandi</a></div></div><div dir=3D"auto"><br></div= ><div><br></div><div align=3D"left" dir=3D"auto" style=3D"font-size:100%;co= lor:#000000"><div>-------- Messaggio originale --------</div><div>Da: andre= <[email protected]> </div><div>Data: 13/08/25 10:58 (GMT+0= 1:00) </div><div>A: [email protected] </div><div>Oggetto: [vwnc] Multiple In= heritance / Generated Hidden Code </div><div><br></div></div>Are there any = existing solutions to multiple-inheritance? <br><br>For deep and UIs and co= mplex resource management, single-inheritance turned out to be painfully li= miting. I happen to waste a lot of time (days, weeks) browsing senders and = implementors to check protocols (the closest thing to "interface") for corr= ectness and conciseness across multiple class hierarchies. There's no way t= o supply protocols with state and (default) behavior. <br><br>Inconsistenci= es are not detected at compile time. Maintaining correctness manually is a = very costly burden. Much of the producivity advantage of Smalltalk is ruine= d this way. With thousands of classes it's almost impossible to be sure tha= t 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 de= als with casting and conflict resolution, at compile time. Generated code c= ould 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 hid= den 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></body></html>= ----_com.samsung.android.email_3602253413433640--