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, s...@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. > >
