On Fri, Mar 18, 2022 at 3:24 PM Todd Blanchard via Pharo-users <pharo-users@lists.pharo.org> wrote:
What, exactly, is inconsistent about a key message isNil being allowed to be overridden?
Overrides are not the issue here.
There is a VERY simple solution to your problem that does not involve disrupting the platform.
No, it's not a simple solution.
But you'd rather change the platform.
I'd bet that the change to inline those message sends came after the implementation of the message sending.
Part of the reason Smalltalk has not been the greatest platform to build software on is its extreme malleability. It is a double edged sword for sure. It is great for research. Not so hot for actual systems development.
You say that Smalltalk is not so hot for system developments because it's extremely malleable? What are you measuring it against?
"The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. <trim>" -Alan Kay
That's exactly the point of this conversion, a user might want the modules to communicate by means of sending messages between them, so writes the code with that expectation and then an external thing (the compiler) decides to do something else that involves not actually sending the message, because it focuses on the "internal properties and behaviors".
The inlined methods implement key operations that I believe *should* be immutable. Because the system is implemented in terms of itself, it is not very hard to completely destroy an image and render it unusable by overriding the wrong message in the wrong class (try overriding #environment at the class level and let me know how long before your image completely packs up under a torrent of walkbacks).
It is still easy to break almost anything, without having to resort to compiler pragmas. :-)
If anything, I would like to see more immutable structure in the core classes. Add methods? Always. Casually override anything? There be dragons there.
Something like "final" classes and "const" globals or not being able to extend classes such as [Proto]Object? In any case, I think the options for this inlining thing were laid on the table, and there is a partial solution for these looking for "semantic optimization" (as in true message sends) rather than performance optimization (as in inlining). Regards! Esteban A. Maringolo
On Mar 18, 2022, at 11:06 AM, sean@clipperadams.com wrote:
I feel like youâve latched onto something that is genuinely a non problemâ¦
I wouldnât call complexity and lack of consistency a ânon problemâ, but it sounds like for you the practical implications outweigh my seemingly-somewhat-ideological/niche concerns. Is that a fair summary? In any case, I appreciate your perspective.