March 2022 - Pharo-users - lists.pharo.org

Re: Null Object Pattern

by James Foster

Richard, 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, at the machine code level you are performing a branch instruction, but when comparing OOP to Procedural Programming we typically make a distinction between âmessagesâ and "procedure calls." The distinction is that the receiver gets to decide how to respond to a message. In C++ this is the distinction between a âvirtual" and "non-virtual" function. By inlining, you are converting the function from a virtual function to a non-virtual function, and this can make a difference (which is why virtual functions exist). How should a proxy (https://en.wikipedia.org/wiki/Proxy_pattern <https://en.wikipedia.org/wiki/Proxy_pattern>) to nil respond to the #âisNilâ message? How should the Null Object Pattern (https://en.wikipedia.org/wiki/Null_object_pattern <https://en.wikipedia.org/wiki/Null_object_pattern>) respond to #âisNilâ? And, yes, Iâm sure you can come up with benchmarks that show a measurable difference, but what is the impact in realistic code? When someone asked about inlining #âyourselfâ in GemStone I believe I measured the performance as taking 2 nanoseconds per call (on a 2012 machine). A 10% speedup would make it 1.8 nanoseconds. Is that worth it? Maybe, maybe not. Note that I described my position as a âconcern,â not an ideological objection. Mostly Iâm giving a rationale for something that doesnât seem to be explained very well for you. I accept that there may be a time for inlining, but I can âcomprehend" another side to the issue. James > On Mar 16, 2022, at 9:42 PM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > We're still not on the same page. > You seem to have some ideological objection to inlining that > I am completely failing to comprehend. > Just because a procedure call (message send) is inlined doesn't > in the least mean it *isn't* a procedure call (message send), > just as compiling a procedure call (message send) as a jump > (last-call optimisation) doesn't mean it *isn't* a procedure > call (message send). > By the way, forget about "40 years ago". > I just did an experiment in Pharo 9, and found that > using "_ ifNotNil: " instead of "_ izNil ifFalse: " > -- where izNil is a non-inlined self == nil -- > gave a 10% speedup, in a test code where real work was going > on as well. > As for turning off all inlining, what do you think that would > do to #ifFalse:ifTrue: and its relatives? > > > On Thu, 17 Mar 2022 at 08:34, <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > > To start with, why do you CARE whether a particular method is inlined or not? > > I care because it makes âeverything is a messageâ a lie! And I suspect (no proof and could be wrong) itâs an optimization that only made sense with the hardware constraints of 40+ years ago. Arguing against premature optimization is hardly something I just made up ;-) > > This makes absolutely no sense to me. What makes you think that the combination "_ isNil ifFalse: [_]" will NOT be inlined? > > I may have been unclear. My intent was to communicate: âIâd like to stop ALL* inlining of messages by default if possibleâ > > *or as many as practical > > The thing that rings loud alarm bells for me is there being "long chains" in the first place. > > I agree that it is in general a smell, but long chains was tangential to the intention above > > Can you give an example? > > I donât know if I can think of one thatâs not contrivedâ¦ Wrapping something external? Squeakâs AppleScript support used to mirror the underlying AS, which is pretty much exactly that. > > In my own programming, I've generally found that nils turning up in the middle of a chain indicates a serious design error somewhere. > > Agreed. See smell comment above. >

March 17, 2022

Re: Null Object Pattern

by Richard O'Keefe

We're still not on the same page. You seem to have some ideological objection to inlining that I am completely failing to comprehend. Just because a procedure call (message send) is inlined doesn't in the least mean it *isn't* a procedure call (message send), just as compiling a procedure call (message send) as a jump (last-call optimisation) doesn't mean it *isn't* a procedure call (message send). By the way, forget about "40 years ago". I just did an experiment in Pharo 9, and found that using "_ ifNotNil: " instead of "_ izNil ifFalse: " -- where izNil is a non-inlined self == nil -- gave a 10% speedup, in a test code where real work was going on as well. As for turning off all inlining, what do you think that would do to #ifFalse:ifTrue: and its relatives? On Thu, 17 Mar 2022 at 08:34, <sean(a)clipperadams.com> wrote: > > To start with, why do you CARE whether a particular method is inlined or > not? > > I care because it makes âeverything is a messageâ a lie! And I suspect (no > proof and could be wrong) itâs an optimization that only made sense with > the hardware constraints of 40+ years ago. Arguing against premature > optimization is hardly something I just made up ;-) > > This makes absolutely no sense to me. What makes you think that the > combination "_ isNil ifFalse: [_]" will NOT be inlined? > > I may have been unclear. My intent was to communicate: âIâd like to stop > ALL* inlining of messages by default if possibleâ > > *or as many as practical > > The thing that rings loud alarm bells for me is there being "long chains" > in the first place. > > I agree that it is in general a smell, but long chains was tangential to > the intention above > > Can you give an example? > > I donât know if I can think of one thatâs not contrivedâ¦ Wrapping > something external? Squeakâs AppleScript support used to mirror the > underlying AS, which is pretty much exactly that. > > In my own programming, I've generally found that nils turning up in the > middle of a chain indicates a serious design error somewhere. > > Agreed. See smell comment above. >

March 17, 2022

Re: Pharo VM Release - v9.0.13

by Russ Whaley

Congratulations! And thanks!! On Wed, Mar 16, 2022 at 6:24 AM tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hello, > I have released a new version of the Pharo VM for Pharo 9 and Pharo 10. > This VM is accessible right now from Zero-Conf, updating it in the Pharo > Launcher or using the usual downloads (as described in pharo.org/download > ). > > This version includes a series of bug fixes. > > Changelog: > > - Correct handling OOB (Out of Band Data) in Window > - Blocking signals while signalling semaphores to avoid deadlocks caused > by signal handlers > - Make MAXHOSTNAMELEN at least 256: improving resolution of names in Linux > - Improving VM Simulator Machine debugger > - Integrating Processor Simulator for RISCV > - Using a new SDL2 version built for OSX Mojave compatibility > > Thanks a lot, and any doubt please let me know. > Cheers, > > Pablo on behalf of the whole Pharo team. > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- Russ Whaley whaley.russ(a)gmail.com

March 17, 2022

Re: Null Object Pattern

by Bernardo Ezequiel Contreras

it's impossible to talk about a project that i don't understand. this sentence *In the second code especially, the problem is that `position` could be many types that are not in the same hierarchy,* draw my attention, because i did many hierarchies when you don't need to do it. just use polymorphic messages, objects that have the same protocol. In that case they don't need to be in the same hierarchy. HTH. On Wed, Mar 16, 2022 at 4:42 PM <sean(a)clipperadams.com> wrote: > if you are using the null object pattern then you should not write those > checks (ifNil:ifNotNil:, isNil, isNotNil). you should send the message to > an instance of the null object and that object should decide what to do. > just an opinion. > > I agree as a general rule, but it can get complicated, especially when > crossing library boundaries. Once one uses a null object, no one anywhere > can use those messages. This might, for example, make experimentation, > refactoring and porting harder. > > At the risk of further distracting the conversation from the question of > inlining, I was having lots of trouble applying the idea you mentioned to > this (low level hack): > > self transcriptable > > ifNil: [ > > self notify: 'Transcript subject not found' > > "We want this to be resumable because maybe e.g. the model just hasn't > been loaded yet" ] > > ifNotNil: [ > > "This is inside the guard because to get the line, we need a subject" > > self line ifNil: [ > > "Brand new snippet" > > self initializeLine. > > ^ self ] ]. > > And this: > > self snippet line position ifNotNil: [ :position | > > self firePlayerRequest: [ :player | player currentPosition: position ] ] > > In the second code especially, the problem is that `position` could be > many types that are not in the same hierarchy, so to send a message to the > null object instead probably means further polluting Object for the > non-null case. > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

March 17, 2022

Re: Null Object Pattern

by Pierre Misse Chanabier

On 3/16/2022 8:33 PM, sean(a)clipperadams.com wrote: > I care because it makes âeverything is a messageâ a lie! And I suspect > (no proof and could be wrong) itâs an optimization that only made > sense with the hardware constraints of 40+ years ago. Arguing against > premature optimization is hardly something I just made up ;-) When I read that, I remember that programming languages are a category of software that cannot run fast enough. So they still make sense more often than not. Moreover the few messages that are inlined (or optimized in general) are heavily used in the core of Pharo. Also, the quote that you're citing, from Donald Knuth, is often if not always used incompletely. I could try to justify it, but I've learned that Scott Meyers is better at explaining things than i'll ever be [1] =) Also, I have been overriding core messages that are optimized (#ifTrue and variant. ifNil and variant and many more) without any problem from the compiler, so I have had no need to disable this inlining. Regardless, you should be able to remove all inlining, it's a matter of tweaking the compiler. However the compiler is one thing that I have touched very little in the system. Pierre Â [1] https://www.youtube.com/watch?v=3WBaY61c9sE

March 16, 2022

Re: Null Object Pattern

by sean＠clipperadams.com

> if you are using the null object pattern then you should not write those > checks (ifNil:ifNotNil:, isNil, isNotNil). you should send the message to > an instance of the null object and that object should decide what to do. > just an opinion. I agree as a general rule, but it can get complicated, especially when crossing library boundaries. Once one uses a null object, no one anywhere can use those messages. This might, for example, make experimentation, refactoring and porting harder. At the risk of further distracting the conversation from the question of inlining, I was having lots of trouble applying the idea you mentioned to this (low level hack): self transcriptable ifNil: \[ self notify: 'Transcript subject not found' "We want this to be resumable because maybe e.g. the model just hasn't been loaded yet" \] ifNotNil: \[ "This is inside the guard because to get the line, we need a subject" self line ifNil: \[ "Brand new snippet" self initializeLine. ^ self \] \]. And this: self snippet line position ifNotNil: \[ :position | self firePlayerRequest: \[ :player | player currentPosition: position \] \] In the second code especially, the problem is that \`position\` could be many types that are not in the same hierarchy, so to send a message to the null object instead probably means further polluting Object for the non-null case.

March 16, 2022

Re: Null Object Pattern

by sean＠clipperadams.com

> To start with, why do you CARE whether a particular > method is inlined or not? I care because it makes âeverything is a messageâ a lie! And I suspect (no proof and could be wrong) itâs an optimization that only made sense with the hardware constraints of 40+ years ago. Arguing against premature optimization is hardly something I just made up ;-) > This makes absolutely no sense to me. What makes you think that the > combination "_ isNil ifFalse: \[_\]" will NOT be inlined? I may have been unclear. My intent was to communicate: âIâd like to stop ALL\* inlining of messages by default if possibleâ \*or as many as practical > The thing that rings loud alarm bells for me is there being "long chains" in the first place. I agree that it is in general a smell, but long chains was tangential to the intention above > Can you give an example? I donât know if I can think of one thatâs not contrivedâ¦ Wrapping something external? Squeakâs AppleScript support used to mirror the underlying AS, which is pretty much exactly that. > In my own programming, I've generally found that nils turning up in the > middle of a chain indicates a serious design error somewhere. Agreed. See smell comment above.

March 16, 2022

Re: [Pharo-dev] Pharo VM Release - v9.0.13

by Arturo Zambrano

Congratulations on the release :-) On Wed, Mar 16, 2022 at 11:24 AM tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hello, > I have released a new version of the Pharo VM for Pharo 9 and Pharo 10. > This VM is accessible right now from Zero-Conf, updating it in the Pharo > Launcher or using the usual downloads (as described in pharo.org/download > ). > > This version includes a series of bug fixes. > > Changelog: > > - Correct handling OOB (Out of Band Data) in Window > - Blocking signals while signalling semaphores to avoid deadlocks caused > by signal handlers > - Make MAXHOSTNAMELEN at least 256: improving resolution of names in Linux > - Improving VM Simulator Machine debugger > - Integrating Processor Simulator for RISCV > - Using a new SDL2 version built for OSX Mojave compatibility > > Thanks a lot, and any doubt please let me know. > Cheers, > > Pablo on behalf of the whole Pharo team. > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- Arturo Zambrano LinkedIn: https://www.linkedin.com/in/arturozambrano/

March 16, 2022

Pharo VM Release - v9.0.13

by tesonep＠gmail.com

Hello, I have released a new version of the Pharo VM for Pharo 9 and Pharo 10. This VM is accessible right now from Zero-Conf, updating it in the Pharo Launcher or using the usual downloads (as described in pharo.org/download) This version includes a series of bug fixes. Changelog: - Correct handling OOB (Out of Band Data) in Window - Blocking signals while signalling semaphores to avoid deadlocks caused by signal handlers - Make MAXHOSTNAMELEN at least 256: improving resolution of names in Linux - Improving VM Simulator Machine debugger - Integrating Processor Simulator for RISCV - Using a new SDL2 version built for OSX Mojave compatibility Thanks a lot, and any doubt please let me know. Cheers, Pablo on behalf of the whole Pharo team. -- Pablo Tesone. tesonep(a)gmail.com

March 16, 2022

Re: BlockClosure folding

by Richard O'Keefe

Pattern? I'd call it an antipattern myself. Note that we can already construct { block1 . block2 . block3 } and write { block1 . block2 . block3 } allSatisfy: [:each | each value]. so we don't have to abuse the #, selector or write a single new method to get the "flattened" structure you're after. Collection methods for: 'collections of blocks' allSatisfied ^self allSatisfy: [:each | each value] anySatisfied ^self anySatisfy: [:each | each value] noneSatisfied ^self noneSatisfy: [:each | each value] if you do feel like adding a few methods, whereupon { block1 . block2 . block3 } allSatisfied Didn't VW recently implement {} syntax natively? Or was that VAST? In all seriousness, when is it better to use ComplexCondition than to rewrite? On Wed, 16 Mar 2022 at 14:38, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > This is an interesting pattern. > Thank you for sharing. > > HernÃ¡n > > El mar, 15 mar 2022 a las 4:43, JuliÃ¡n Maestri (<serpi90(a)gmail.com>) > escribiÃ³: > >> Not satisfying the equality, but you can use polymorphism. >> >> Block >> , aBlock >> ^ BlockCompositor andAll: OrderedCollection with: self with: aBlock >> >> BlockCompositor >> #, aBlock >> conditions add: aBlock. >> >> BlockCompositor >> value: anObject >> ^ conditions allSatisfy: [:e | e value: anObject ] >> >> I don't really like the name BlockCompositor, but can't think of a better >> name at the moment. >> >> You could also implement logic for #or: using #+ and: #anySatisfy: for >> example, but need to safeguard against mixing both conditions. >> >> On Mon, 14 Mar 2022 at 22:29, HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com> wrote: >> >>> I think I saw a coding pattern a while ago that allows you to do the >>> following: >>> >>> cond1 , cond2 , cond3 , cond4 >>> >>> And providing a kind of folding selector condition #and: you would get: >>> >>> [ cond1 and: [ cond2 and: [ cond3 and: [ cond4 ] ] ] ]. >>> >>> for example: >>> >>> conditions := [ : each | each firstName = 'Boca' ] , >>> [ : each | each lastName = 'Baret' ] , >>> [ : each | each fullName = 'Virgasia' ]. >>> >>> such that the following assert is met: >>> >>> self assert: conditions equals: [ : each | each firstName = 'Boca' and: >>> [ each lastName = 'Baret' and: [ each fullName = 'Virgasia' ] ] ]. >>> >>> Any ideas or pointers? >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>>

March 16, 2022