April 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by Esteban Lorenzano

> On 7 Apr 2017, at 11:59, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 7 Apr 2017, at 10:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hi, there is a rule that suggests to use and/or boolean operations instead of multiple returns. >> >> For example it suggests agains using: >> >> isTranslucentButNotTransparent >> >> backgroundColor ifNil: [ ^ true ]. >> (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >> (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >> ^ false >> >> Instead you should use: >> >> isTranslucentButNotTransparent >> >> ^ backgroundColor isNil or: [ >> (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ >> borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ] >> >> And at least a few developers think that the suggested implementation is more complicated to comprehend. >> >> What is the reasoning behind the rule? Does the suggested version run faster (i.e. is optimized ing some way?). > > I disagree with such rule. Is confusing and unnecessary. > > The âescape conditionâ is clearer and easier to understand. > And methods that are composed like this: > > a = x1 ifTrue: [ ^ r1 ]. > a = x2 ifTrue: [ ^ r2 ]. > â¦ > etc. > > are very common because they are (again) legible and can be easily optimised by the JIT. > > (they are even called âcase methodsâ somewhere I do not remember :P) of course better way to deal with this is to use double dispatch, but you cannot always do it ;) > > Esteban > >> >> Cheers. >> Uko

April 7, 2017

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by Esteban Lorenzano

> On 7 Apr 2017, at 10:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi, there is a rule that suggests to use and/or boolean operations instead of multiple returns. > > For example it suggests agains using: > > isTranslucentButNotTransparent > > backgroundColor ifNil: [ ^ true ]. > (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > ^ false > > Instead you should use: > > isTranslucentButNotTransparent > > ^ backgroundColor isNil or: [ > (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ > borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ] > > And at least a few developers think that the suggested implementation is more complicated to comprehend. > > What is the reasoning behind the rule? Does the suggested version run faster (i.e. is optimized ing some way?). I disagree with such rule. Is confusing and unnecessary. The âescape conditionâ is clearer and easier to understand. And methods that are composed like this: a = x1 ifTrue: [ ^ r1 ]. a = x2 ifTrue: [ ^ r2 ]. â¦ etc. are very common because they are (again) legible and can be easily optimised by the JIT. (they are even called âcase methodsâ somewhere I do not remember :P) Esteban > > Cheers. > Uko

April 7, 2017

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by Denis Kudriashov

2017-04-07 11:23 GMT+02:00 marcus.denker(a)inrira.fr <marcus.denker(a)inria.fr>: > I really do not like the complex boolean expressionsâ¦ my brain can > understand the âcheck and returnâ guards extremely fast: > > backgroundColor ifNil: [ ^ true ]. > (backgroundColor isColor and: [ backgroundColor > isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > (borderColor isColor and: [ borderColor > isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > ^ false > > while for the nesting everything in one huge or: /and: expression I have > to think. I always feel that replacing the âguardâ > style with complex nested booleans makes the code worse. > > I really would like to remove the rule. > Me too

April 7, 2017

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by marcus.denker＠inrira.fr

> On 7 Apr 2017, at 10:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi, there is a rule that suggests to use and/or boolean operations instead of multiple returns. > > For example it suggests agains using: > > isTranslucentButNotTransparent > > backgroundColor ifNil: [ ^ true ]. > (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > ^ false > > Instead you should use: > > isTranslucentButNotTransparent > > ^ backgroundColor isNil or: [ > (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ > borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ] > > And at least a few developers think that the suggested implementation is more complicated to comprehend. > I really do not like the complex boolean expressionsâ¦ my brain can understand the âcheck and returnâ guards extremely fast: backgroundColor ifNil: [ ^ true ]. (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. ^ false while for the nesting everything in one huge or: /and: expression I have to think. I always feel that replacing the âguardâ style with complex nested booleans makes the code worse. I really would like to remove the rule. Marcus

April 7, 2017

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by Nicolas Cellier

2017-04-07 11:03 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi Yuriy, > to me the first form is a list of simple rules. > The second one is a complex expression > > You made an effort to keep the list format for the second expression, > while violating traditional block formatting which would be > > > > ^ backgroundColor isNil > or: [ > (backgroundColor isColor and: [ backgroundColor > isTranslucentButNotTransparent ]) or: [ > borderColor isColor and: [ borderColor > isTranslucentButNotTransparent ] ] ] > > Sorry, premature post caused by missuse of tab key, traditional format could be something like: isTranslucentButNotTransparent ^ backgroundColor isNil or: [ (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ] Personnally, I like this indentation better. It's still preserving the list of simple rules, and indicate a hierarchy among the rules But indentations sounds overkill and won't scale very high. To me the first form is nearer the pattern matching style of a functional language. > I don't think that runtime optimization count at all in such choice. > > 2017-04-07 10:33 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Hi, there is a rule that suggests to use and/or boolean operations >> instead of multiple returns. >> >> For example it suggests agains using: >> >> isTranslucentButNotTransparent >> >> backgroundColor ifNil: [ ^ true ]. >> (backgroundColor isColor and: [ backgroundColor >> isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >> (borderColor isColor and: [ borderColor >> isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >> ^ false >> >> Instead you should use: >> >> isTranslucentButNotTransparent >> >> ^ backgroundColor isNil or: [ >> (backgroundColor isColor and: [ backgroundColor >> isTranslucentButNotTransparent ]) or: [ >> borderColor isColor and: [ borderColor >> isTranslucentButNotTransparent ] ] ] >> >> And at least a few developers think that the suggested implementation is >> more complicated to comprehend. >> >> What is the reasoning behind the rule? Does the suggested version run >> faster (i.e. is optimized ing some way?). >> >> Cheers. >> Uko >> > >

April 7, 2017

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by Nicolas Cellier

Hi Yuriy, to me the first form is a list of simple rules. The second one is a complex expression You made an effort to keep the list format for the second expression, while violating traditional block formatting which would be ^ backgroundColor isNil or: [ (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ] I don't think that runtime optimization count at all in such choice. 2017-04-07 10:33 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, there is a rule that suggests to use and/or boolean operations instead > of multiple returns. > > For example it suggests agains using: > > isTranslucentButNotTransparent > > backgroundColor ifNil: [ ^ true ]. > (backgroundColor isColor and: [ backgroundColor > isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > (borderColor isColor and: [ borderColor > isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > ^ false > > Instead you should use: > > isTranslucentButNotTransparent > > ^ backgroundColor isNil or: [ > (backgroundColor isColor and: [ backgroundColor > isTranslucentButNotTransparent ]) or: [ > borderColor isColor and: [ borderColor > isTranslucentButNotTransparent ] ] ] > > And at least a few developers think that the suggested implementation is > more complicated to comprehend. > > What is the reasoning behind the rule? Does the suggested version run > faster (i.e. is optimized ing some way?). > > Cheers. > Uko >

April 7, 2017

Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by Yuriy Tymchuk

Hi, there is a rule that suggests to use and/or boolean operations instead of multiple returns. For example it suggests agains using: isTranslucentButNotTransparent backgroundColor ifNil: [ ^ true ]. (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. ^ false Instead you should use: isTranslucentButNotTransparent ^ backgroundColor isNil or: [ (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ] And at least a few developers think that the suggested implementation is more complicated to comprehend. What is the reasoning behind the rule? Does the suggested version run faster (i.e. is optimized ing some way?). Cheers. Uko

April 7, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60462 Home: https://github.com/pharo-project/pharo-core

April 6, 2017

[pharo-project/pharo-core] 3eb66e: 60462

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3eb66ebe154ff17a1e13a35ae2337913221b8a8e https://github.com/pharo-project/pharo-core/commit/3eb66ebe154ff17a1e13a35a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-06 (Thu, 06 Apr 2017) Changed paths: A Athens-Cairo.package/CairoLibrary.class/instance/accessing platform/unix32ModuleName.st A Athens-Cairo.package/CairoLibrary.class/instance/accessing platform/unix64ModuleName.st M Athens-Cairo.package/CairoLibrary.class/instance/accessing platform/unixModuleName.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60461.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60462.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60461.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60462.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60462 19921 allow CairoLibrary to find x86_64 bits libcairo when needed (linux) https://pharo.fogbugz.com/f/cases/19921 http://files.pharo.org/image/60/60462.zip

April 6, 2017

Re: [Pharo-dev] ftp repositories broken

by Eliot Miranda

> On Apr 5, 2017, at 1:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi guys. > > I could not accept your explanation because I have test which works on latest squeakVM and not works on latest pharoVM. Try filein attachment and check it on both VMs. Test not depends on any difference between squeak and pharo images. You run it on both systems (not only VM's). > I found that #primitiveFindSubstring not depends on receiver and you can put it on any class in system (in github C code there is no users of "rcvr" variable). So I just copy primitive method in test class. > > But I could imaging that I not see/know something trivial. I will be glad to expand my mind :) but I see only reason: primitive is different (or absent) on latest pharoVM. Can we not simply compare the sources of src/plugins/MiscPrimitivesPlugin/MiscPrimitivesPlugin.c in the two VMs? (If we were using one set of sources this issue would be moot). > > 2017-04-04 19:03 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> On 4 Apr 2017, at 19:00, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> >>> 2017-04-04 18:45 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> > I think you are wrong because I check it carefully in Squeak and I found it on github https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=â&q=primiti…. >>>> >>>> still is not there, because is not the same primitive :) >>> >>> Does it also means that latest VM is built differently then stable? (primitive works on stable pharo). I just thought that we already moved to opensmalltalk build process. >> >> stable works because the bug ByteString>>#findâ¦ instead of String>>#findâ¦ was introduced later. >> > > <FindStringPrimitiveTests.st>

April 6, 2017