- Pharo-users - lists.pharo.org

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

Re: BlockClosure folding

by Richard O'Keefe

The motivating example can be written aHasDot := a includes: $.. bHasDot := b includes: $.. ^aHasDot = bHasDot ifFalse: [bHasDot] ifTrue: [aHasDot ifTrue: [a < b] ifFalse: [a > b]] (Dijkstra was right. People *do* forget that '=' is one of the standard Boolean operations, and it matters.) This is absolutely straightforward, and without wasting any time wondering what the three-headed IF monster is, we can go straight to the big puzzle: "I can see at a glance what this DOES, but what the heck does it MEAN?" When would this be useful? What would be a good name for this combination, however expressed? I think the moral here is "when you have code whose structure is so complex that you are tempted to construct special control flow objects to make it LOOK simpler, rewrite it so that it IS simpler." I once wrote a class called Distributor based on Boost 'signal's. It was an interesting exercise, and I am still finding mistakes in it. It was not entirely unlike ComplexCondition. What I *haven't* done in the 10 years since I wrote it is found any use for it. On Wed, 16 Mar 2022 at 07:15, <sean(a)clipperadams.com> wrote: > ComplexCondition as described in Andres Valloud, "A Mentoring Course on > Smalltalk" > <http://www.lulu.com/product/paperback/a-mentoring-course-on-smalltalk/37888…> > is available at http://www.squeaksource.com/ComplexCondition.html > > With it, you can do something like: > > ^[a includes: $.], [b includes: $.] > ifAllTrue: [a < b] > ifAnyTrue: [b includes: $.] > otherwise: [a > b] > >

March 16, 2022

Re: BlockClosure folding

by HernÃ¡n Morales Durand

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

Re: BlockClosure folding

by HernÃ¡n Morales Durand

Exactly. This was what I was looking for. Thank you Sean. HernÃ¡n El mar, 15 mar 2022 a las 19:15, <sean(a)clipperadams.com> escribiÃ³: > ComplexCondition as described in Andres Valloud, "A Mentoring Course on > Smalltalk" > <http://www.lulu.com/product/paperback/a-mentoring-course-on-smalltalk/37888…> > is available at http://www.squeaksource.com/ComplexCondition.html > > With it, you can do something like: > > ^[a includes: $.], [b includes: $.] > ifAllTrue: [a < b] > ifAnyTrue: [b includes: $.] > otherwise: [a > b] > >

March 16, 2022

Re: Null Object Pattern

by Todd Blanchard

Why do you not just do something like [ âcomplicated code that might fail somewhere in hereâ ] on: Error do: [:error | nil] Use the on:do: exception handling to stay safe. Result := [anObject long chain of messages that might return a nilValue ] on: Error do: [:e | nil]. > On Mar 15, 2022, at 11:16 AM, sean(a)clipperadams.com wrote: > > I had some chaining that was getting too complex due to many nil checks, so I started to refactor using a Null Object. > > However, Iâm struggling a bit with the refactor due to inlining. Since #ifNil: variants might be inlined, it seems that something like: > > anObject with a long chain of messages ifNotNil: [ :result | ââ¦â ] > > must be changed into something like: > > anObject with a long chain of messages isNil ifFalse: [ anObject with a long chain of messages ââ¦â ]. > > Obviously, I can use a temp to have: > > result := anObject with a long chain of messages. > > result isNil ifFalse: [ result ââ¦â ]. > > But both seem ugly and make me question using this pattern. > > What am I missing? > > After 40+ years of Mooreâs Law, can we turn off these inlines by default? >

March 16, 2022