What, exactly, is inconsistent about a key message isNil being allowed to be overridden?
There is a VERY simple solution to your problem that does not involve disrupting the platform. But you'd rather change the platform. 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. "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. Think of the internet – to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas." -Alan Kay 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). If anything, I would like to see more immutable structure in the core classes. Add methods? Always. Casually override anything? There be dragons there. > 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. >
