Re: [Pharo-dev] Updated tech talk archive

[marcus.den...@inrira.fr]

Good idea! 

Pharo Tech talk Jun has no topic yet, so we could use that.

Marcus

> On 26 Apr 2017, at 16:18, Ben Coman <b...@openinworld.com> wrote:
> 
> Thanks Marcus. 
> I see the schedule here... https://association.pharo.org/events 
> <https://association.pharo.org/events>
> doesn't mention Pharo 7 development process. 
> I think that will be useful to have a presentation.
> Maybe a special-edition TechTalk aligned shortly after Pharo 6 Release?
> 
> cheers -ben
> 
> On Wed, Apr 26, 2017 at 7:09 PM, marcus.den...@inrira.fr 
> <mailto:marcus.den...@inrira.fr> <marcus.den...@inria.fr 
> <mailto:marcus.den...@inria.fr>> wrote:
> http://pharo.org/TechTalk <http://pharo.org/TechTalk>
> 
> Now has a link to the recoding of yesterday
> 
>   Marcus
> 

[Pharo-dev] Updated tech talk archive

[marcus.den...@inrira.fr]

http://pharo.org/TechTalk 

Now has a link to the recoding of yesterday

Marcus

Re: [Pharo-dev] [ANN] Pharo Spring Friday, April 28

[marcus.den...@inrira.fr]

Hello,

I can change all the pages as wanted..  (sorry for being a bit absent right 
now).

For links to the events, there should be a way… I will check (sometimes this 
week).

> On 24 Apr 2017, at 16:42, Juraj Kubelka <juraj.kube...@icloud.com> wrote:
> 
> Hi Marcus,
> 
> it is a detail, but the events mentions Slack. Maybe it should mention 
> Discord.
> 
> I would like to improve the page http://pharo.org/contribute-events 
> <http://pharo.org/contribute-events> 
> by adding a workflow and link to the Pharo Sprint App. How can I do it? 
> 
> Also it would be nice to have the https://association.pharo.org/event-2492488 
> <https://association.pharo.org/event-2492488> (and others) visible on that 
> page. 
> Is it possible? Is there any calendar plugin that we can plug to the 
> http://pharo.org/contribute-events <http://pharo.org/contribute-events>? 
> 
> I am happy to collaborate on this, if you (or someone else) explain me how to 
> contribute to the web page.
> 
> Thanks!
> Juraj
> 
>> On Apr 24, 2017, at 10:55, marcus.den...@inrira.fr 
>> <mailto:marcus.den...@inrira.fr> <marcus.den...@inria.fr 
>> <mailto:marcus.den...@inria.fr>> wrote:
>> 
>> Hi,
>> 
>> There will be again a Sprint this Friday.
>> 
>> More infos here:
>> 
>>  https://association.pharo.org/event-2492488 
>> <https://association.pharo.org/event-2492488>
>> 
> 

[Pharo-dev] [ANN] Pharo Spring Friday, April 28

[marcus.den...@inrira.fr]

Hi,

There will be again a Sprint this Friday.

More infos here:

https://association.pharo.org/event-2492488

Re: [Pharo-dev] esteban is on vacation this week....

[marcus.den...@inrira.fr]

I am not available either. If on holiday or not is hard to say as plans change 
literally every day,
but if what is planed now will work out (I do not believe in that concept 
anymore, though), then
everything gets better starting Mai 1.

Marcus

> On 16 Apr 2017, at 13:32, Stephane Ducasse  wrote:
> 
> like that you understand why he is no replying
> 

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

[marcus.den...@inrira.fr]

> 
> 1) it’s not only about removing. Maybe we should detect complicated boolean 
> expressions that return something and suggest to break them down.

No idea…

> 2) I just want to know why someone created such rule :). Because the author 
> of the last update of the initialize method is Marcus :)
> 

I did not add it originally.

Marcus

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

[marcus.den...@inrira.fr]

> On 7 Apr 2017, at 10:33, Yuriy Tymchuk  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