[Pharo-users] Re: Null Object Pattern
> On 17 Mar 2022, at 18:00, Esteban Maringolo wrote: > > That is great! > > Is it possible to disable it for doits and other playground expressions? > No, there is no hook yet… it would be interesting to see how to do that. (e.g. per playground compiler parameters, parameters for doit independent of the compiler used for compiling methods…) What you can do is turning it off globally in the setting (all compiler option are listed there) But take care: we can not recompile the image without optimzations as this adds intererrupt possibilities to code that was not interruptable before, which breaks the code in for process switching itself, I think. > Regards! > > Esteban A. Maringolo > > On Thu, Mar 17, 2022 at 1:23 PM Marcus Denker wrote: >> On 17 Mar 2022, at 17:17, Richard Sargent >> wrote: >> A pragma might be the way to go. >> for example. >> >> >> >> There is already the #compilerOptions: Pragma, e.g.: >> >> >> For example this method compiled the and: as a real send: >> tt >> >> true and: [ false ] >> >> >> On Thu, Mar 17, 2022 at 8:17 AM Esteban Maringolo >> wrote: > >>> A great trade off would be to be able >>> to enable/disable for certain things instead of it being a global >>> setting.
[Pharo-users] Re: Null Object Pattern
> My *concern* with inlining is that since it is designed to short-circuit > dynamic method lookup, it is impossible to call a *different* implementation. > That is, you lose the opportunity to have the *receiver* decide how to > respond to the message. You may think of it as a message, but the caller is > deciding how the receiver will respond—which largely defeats the purpose and > role of it being a message. Yes, this is exactly the point I was (apparently badly) trying to convey. Thanks!
[Pharo-users] Re: Null Object Pattern
> My chief concern is that I am a bear of very little brain, > and if you change the meaning of #isNil to anything at all > other than "is the receiver identical to nil" you *WILL* > (not may) confuse me. I can understand your probably well-justified concern that power can always be misused. I also understand a key principle of Smalltalk to be “empower and trust the programmer”. Edge cases like this where Smalltalk principles like pervasive message passing are not true bring their own share of confusion. > "How should a proxy (https://en.wikipedia.org/wiki/Proxy_pattern) to nil > respond to the #’isNil’ message?" > > It SHOULD NOT LIE. A proxy *isn't* nil, and it doesn't *behave* like nil, > even if it is a proxy for nil. A proxy, qua proxy, can do things that nil > cannot. Use another selector, #isEffectivelyNil, or whatever reveals your > intentions, and give it what semantics you find useful. I find the concept of “is” and “equal” to be generally confusing in Smalltalk. Does \`#=\` mean “all state is the same”? “all relevant state is the same (minus e.g. caching)”? “This represents the same domain object”? I can see how a proxy claiming to be nil is a “lie” for one/some definitions of “is”, but I don’t think it’s universally true. Really interesting conversation!
[Pharo-users] Re: Null Object Pattern
> What you can do is turning it off globally in the setting (all compiler > option are listed there) > > But take care: we can not recompile the image without optimzations as this > adds intererrupt possibilities to code that was not > interruptable before, which breaks the code in for process switching itself, > I think. So it sounds like my daydream that inlining be turned off by default is a heavier lift than just flipping a switch, correct? In principle (ignoring the amount of work involved) what are your thoughts RE my musing: “After 40+ years of Moore’s Law, can we turn off these inlines by default?” and my hypothesis that this is an optimization that made sense at the time but now adds complexity for questionable payoff?
[Pharo-users] Re: Null Object Pattern
I feel like you’ve latched onto something that is genuinely a non problem and if you get your way we all suffer reduced performance and a guarantee that a nil test is universally the same thing. If you want an overridable nil test, write your own nil test like isNilish and make it mean what you like without disrupting the rest of the system. Problem solved and you’re not violating the open closed principle. Sent from my iPhone > On Mar 18, 2022, at 8:39 AM, s...@clipperadams.com wrote: > > > What you can do is turning it off globally in the setting (all compiler > option are listed there) > > But take care: we can not recompile the image without optimzations as this > adds intererrupt possibilities to code that was not interruptable before, > which breaks the code in for process switching itself, I think. > > So it sounds like my daydream that inlining be turned off by default is a > heavier lift than just flipping a switch, correct? > > In principle (ignoring the amount of work involved) what are your thoughts RE > my musing: “After 40+ years of Moore’s Law, can we turn off these inlines by > default?” and my hypothesis that this is an optimization that made sense at > the time but now adds complexity for questionable payoff?
[Pharo-users] Re: Null Object Pattern
> 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.
[Pharo-users] Re: Null Object Pattern
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. >
[Pharo-users] Re: Null Object Pattern
On Fri, Mar 18, 2022 at 3:24 PM Todd Blanchard via Pharo-users 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. " -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. > >
[Pharo-users] Re: Null Object Pattern
> On Mar 18, 2022, at 11:39 AM, Esteban Maringolo wrote: > > You say that Smalltalk is not so hot for system developments because > it's extremely malleable? What are you measuring it against? Lots of things but to keep things simple lets go with Objective C since it is quite similar in concept and style but the library classes are closed to modification without extraordinary effort (you can replace a method but you're gonna have to work to do it because you don't have the source code for the core classes). > > It is still easy to break almost anything, without having to resort to > compiler pragmas. :-) Yeah, that's kind of my point. I have junked a lot of images in my wake. >> 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? IDK exactly. Yeah, maybe a pragma that was part of the core library that would prevent an override of a key method that say, the browser, depends on. Smalltalk is great for building things, but unlike when I build, say, a car, I don't have to drag around the entire factory I used to build the car behind it everywhere. Toying with the idea of using one image to host remote developer tools that we do not change and using it to operate on a second image that has minimal dev tools but will be the production version of my app. That would provide the separation that would keep me from destroying toolkit by accident while trying to tweak the app. Just musing here. I've become kind of dissatisfied with Pharo development of late. Hard to build anything that lasts very long. > > > >> >> 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. >> >>
