May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Null Coalesce Operator?

by Aliaksei Syrel

On Wed, May 20, 2015 at 10:14 PM, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > would generate a new OrderedCollection every time it is called!. Even > more overkill. Last line from previous email: Blocks are of course better, because they are lazy and don't get executed if value is not nil - complete opposite to null coalescing operator. That is the price that should be payed. Cheers, Alex

May 20, 2015

Re: [Pharo-dev] FileSystem not deleting symlinks

by Sean P. DeNigris

Damien Pollet wrote > Perhaps a risk of deleting the symlink target instead of the link itself? IIRC before the VM changes to distinguish symlinks, that was exactly the dangerous situation. If you had a symlink to your home directory in a folder which you deleted from Pharo... bye bye :/ ----- Cheers, Sean -- View this message in context: http://forum.world.st/FileSystem-not-deleting-symlinks-tp4827629p4827725.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 20, 2015

Re: [Pharo-dev] Null Coalesce Operator?

by Chris Cunningham

On Wed, May 20, 2015 at 12:55 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Check for the nil value should be banned in my opinion. There are >> well-known techniques to not have to use it (e.g., Null-object pattern). > > Absolutely agree! :) > > My only fear is that it could encourage the use of nil instead of proper >> Null Objects > > Sometimes it's impossible to always have Null Object in first place and we > still have to do something like this: > > default1 ifNil: [ "Null object" ]. > > > I even saw in many places > > values >> ^ values ifNil: [ OrderedCollection new ] > > > And it perfectly works. However, usage of blocks for such simple checks > looks like overhead, isn't it? > <snip> Block may be overkill - but an infix, at least in classic smalltalk, means that both sides of the operator get's evaluated. So, values ^ values && OrderedCollection new would generate a new OrderedCollection every time it is called!. Even more overkill. Or, if you use it for lazy initialization like: values ^ values && (values := OrderedCollection new) you would keep re-initializing values. Try loading those messages and then doing: a := Array with: 'Original Object' " ==> #('Original Object') " a && (OrderedCollection new) " ==> #('Original Object') " a " ==> an OrderedCollection() " Without more extensive changes than just adding this, we'd be setting up users for a huge amount of trouble in the future. -cbc

May 20, 2015

Re: [Pharo-dev] Null Coalesce Operator?

by Aliaksei Syrel

> > Check for the nil value should be banned in my opinion. There are > well-known techniques to not have to use it (e.g., Null-object pattern). Absolutely agree! :) My only fear is that it could encourage the use of nil instead of proper > Null Objects Sometimes it's impossible to always have Null Object in first place and we still have to do something like this: default1 ifNil: [ "Null object" ]. I even saw in many places values > ^ values ifNil: [ OrderedCollection new ] And it perfectly works. However, usage of blocks for such simple checks looks like overhead, isn't it? (and for modern kids it looks ugly too). Take a look how many languages already support ??: C#, Swift, PHP7 (yes, these php-coders had to wait until 7th version), JavaScript, Groovy (they name it Evil Operator), Objective-C. But yes, nils are evil :) Blocks are of course better, because they are lazy and don't get executed if value is not nil - complete opposite to null coalescing operator. Cheers, Alex On Wed, May 20, 2015 at 9:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, #ifNil: is almost the same (except the #value): > > |default1 default2 default3 default4 | > default1 := nil. > default2 := nil. > default3 := 'foo'. > default4 := 'don''t care'. > default1 ifNil: [ default2 ifNil: [ default3 ifNil: [ default4 ] ] ] > > => 'foo' > > > On 20 May 2015, at 21:38, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > > > â¦ifNone: is a nice idiom, but not always available (in which case, we > should think about introducing it) > > > > ?? is basically an infix but eager version of #ifNil:, IMHO a pragmatic > thing to have; could be quite handy. > > My only fear is that it could encourage the use of nil instead of proper > Null Objectsâ¦ and here we start bikeshedding > > > > On 20 May 2015 at 21:31, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > > > > In my experience those situations end up been handled by collections, > detect:ifNone: which even handles the case when all defaults are nil. > > > > But maybe that idiom is very common in another situations. > > > > > > > > -- > > Damien Pollet > > type less, do more [ | ] http://people.untyped.org/damien.pollet > > >

May 20, 2015

Re: [Pharo-dev] about the donwload win.zip pharo 40

by Max Leske

> On 20 May 2015, at 20:46, stepharo <stepharo(a)free.fr> wrote: > > Hi > > one student of saint-louis tried to download pharo from the pharo web site > and on windows the archive seems broken. > > Could someone try and let me know? Works perfectly on Win 8 (Virtualbox). The only thing I can think of is that someone might try to open the archive unpacked (which will promt for the image file). So it is definitely not corrupt. Cheers, Max > > Tx. > > Stef >

May 20, 2015

Re: [Pharo-dev] Null Coalesce Operator?

by Sven Van Caekenberghe

Yes, #ifNil: is almost the same (except the #value): |default1 default2 default3 default4 | default1 := nil. default2 := nil. default3 := 'foo'. default4 := 'don''t care'. default1 ifNil: [ default2 ifNil: [ default3 ifNil: [ default4 ] ] ] => 'foo' > On 20 May 2015, at 21:38, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > â¦ifNone: is a nice idiom, but not always available (in which case, we should think about introducing it) > > ?? is basically an infix but eager version of #ifNil:, IMHO a pragmatic thing to have; could be quite handy. > My only fear is that it could encourage the use of nil instead of proper Null Objectsâ¦ and here we start bikeshedding > > On 20 May 2015 at 21:31, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > > In my experience those situations end up been handled by collections, detect:ifNone: which even handles the case when all defaults are nil. > > But maybe that idiom is very common in another situations. > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

May 20, 2015

Re: [Pharo-dev] Null Coalesce Operator?

by Damien Pollet

â¦ifNone: is a nice idiom, but not always available (in which case, we should think about introducing it) ?? is basically an infix but eager version of #ifNil:, IMHO a pragmatic thing to have; could be quite handy. My only fear is that it could encourage the use of nil instead of proper Null Objectsâ¦ and here we start bikeshedding On 20 May 2015 at 21:31, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > > In my experience those situations end up been handled by collections, > detect:ifNone: which even handles the case when all defaults are nil. > > But maybe that idiom is very common in another situations. > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 20, 2015

Re: [Pharo-dev] [Pharo 5] For testing: enabled AST based syntax higlighting

by Sergio Fedi

Sooooo cool.â

May 20, 2015

Re: [Pharo-dev] about the donwload win.zip pharo 40

by Sergio Fedi

Worked for me too.â

May 20, 2015

Re: [Pharo-dev] Null Coalesce Operator?

by Sergio Fedi

In my experience those situations end up been handled by collections, detect:ifNone: which even handles the case when all defaults are nil. But maybe that idiom is very common in another situations.

May 20, 2015