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 :)
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.
â¦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@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
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@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@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
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@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@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@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
On Wed, May 20, 2015 at 12:55 PM, Aliaksei Syrel <alex.syrel@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
On Wed, May 20, 2015 at 10:14 PM, Chris Cunningham <cunningham.cb@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
Yes, let's not introduce it :) Not a smalltalk way! Cheers, Alex On Wed, May 20, 2015 at 10:27 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
On Wed, May 20, 2015 at 10:14 PM, Chris Cunningham < cunningham.cb@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
Hi Aliaksei, On Wed, May 20, 2015 at 12:55 PM, Aliaksei Syrel <alex.syrel@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 <sven@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@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@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
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.syrel@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 :)
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 <
alex.syrel@
> 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 :)
-- 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.
participants (8)
-
Alexandre Bergel -
Aliaksei Syrel -
Chris Cunningham -
Damien Pollet -
Eliot Miranda -
Richard Sargent -
Sergio Fedi -
Sven Van Caekenberghe