Re: [Pharo-dev] Null Coalesce Operator?
abergel wrote Hi! I perfectly understand the purpose of this method ??” Although I do not think this will seriously impact the quality of the code being produced, ... Actually, I would argue it that it would degrade the quality of code. There is less clarity conveyed by infix operators than by keyword messages, unless the infix operator is already well known (such as common arithmetic operators) or somewhat easily guessed (such as #~=). #?? only has meaning if you already know it from other languages. ... I still believe it will not help making code of a better quality. 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). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On May 20, 2015, at 3:19 PM, Aliaksei Syrel lt; alex.syrel@ gt; wrote: Hi, Null coalesce operator - returns the first not nil operand. http://en.wikipedia.org/wiki/Null_coalescing_operator lt;http://en.wikipedia.org/wiki/Null_coalescing_operatorgt; Adding one simple method to an Object: ?? anObject ^ self and to UndefinedObject: ?? anObject ^ anObject could allow us to write: default1 := nil. default2 := nil. default3 := 'foo'. default4 := 'don''t care'. config := default1 ?? default2 ?? default3 ?? default4. = 'foo' I know you don't like to add new methods to an object, but still :) -- View this message in context: http://forum.world.st/Null-Coalesce-Operator-tp4827707p4827911.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Null Coalesce Operator?
On Wed, May 20, 2015 at 12:55 PM, Aliaksei Syrel alex.sy...@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
Re: [Pharo-dev] Null Coalesce Operator?
On Wed, May 20, 2015 at 10:14 PM, Chris Cunningham cunningham...@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
Re: [Pharo-dev] Null Coalesce Operator?
Yes, let's not introduce it :) Not a smalltalk way! Cheers, Alex On Wed, May 20, 2015 at 10:27 PM, Aliaksei Syrel alex.sy...@gmail.com wrote: On Wed, May 20, 2015 at 10:14 PM, Chris Cunningham cunningham...@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
Re: [Pharo-dev] Null Coalesce Operator?
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 s...@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.pol...@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.f...@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
[Pharo-dev] Null Coalesce Operator?
Hi, Null coalesce operator - returns the first not nil operand. http://en.wikipedia.org/wiki/Null_coalescing_operator Adding one simple method to an Object: ?? anObject ^ self and to UndefinedObject: ?? anObject ^ anObject could allow us to write: default1 := nil. default2 := nil. default3 := 'foo'. default4 := 'don''t care'. config := default1 ?? default2 ?? default3 ?? default4. = 'foo' I know you don't like to add new methods to an object, but still :)
Re: [Pharo-dev] Null Coalesce Operator?
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.pol...@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.f...@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
Re: [Pharo-dev] Null Coalesce Operator?
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.
Re: [Pharo-dev] Null Coalesce Operator?
Hi! I perfectly understand the purpose of this method ??” Although I do not think this will seriously impact the quality of the code being produced, I still believe it will not help making code of a better quality. 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). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On May 20, 2015, at 3:19 PM, Aliaksei Syrel alex.sy...@gmail.com wrote: Hi, Null coalesce operator - returns the first not nil operand. http://en.wikipedia.org/wiki/Null_coalescing_operator http://en.wikipedia.org/wiki/Null_coalescing_operator Adding one simple method to an Object: ?? anObject ^ self and to UndefinedObject: ?? anObject ^ anObject could allow us to write: default1 := nil. default2 := nil. default3 := 'foo'. default4 := 'don''t care'. config := default1 ?? default2 ?? default3 ?? default4. = 'foo' I know you don't like to add new methods to an object, but still :)
Re: [Pharo-dev] Null Coalesce Operator?
…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.f...@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
Re: [Pharo-dev] Null Coalesce Operator?
Hi Aliaksei, On Wed, May 20, 2015 at 12:55 PM, Aliaksei Syrel alex.sy...@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? (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. ifNil:, ifNotNil:, ifNotNil:ifNil: and ifNil:ifNotNil: all get inlines as per ifTrue: et al, so no blocks are created The only overhead is syntactic. Cheers, Alex On Wed, May 20, 2015 at 9:41 PM, Sven Van Caekenberghe s...@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.pol...@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.f...@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 -- best, Eliot
