but not putting it on Object would change the feature since you do want it returning self on that case. But from your comment we can take the idea of adding it in Object, UndefinedObject and Collection and it will be a faster implementation since it will be trivial for the three of them, no?

On Jan 4, 2015, at 8:40 PM, Benoit St-Jean <bstjean@yahoo.com> wrote:

A cleaner implementation would be to define this method in UndefinedObject and Collection only. It should not appear in Object, the same way #isEmptyOrNil is defined.

----------------- Benoit St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean IRC: lamneth Blogue: endormitoire.wordpress.com

"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

From: Sebastian Sastre <sebastian@flowingconcept.com> To: Pharo Development List <pharo-dev@lists.pharo.org> Sent: Sunday, January 4, 2015 5:27 PM Subject: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

Hi guys,

I’ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

self ifNil: [ ^ aBlock value ].

(self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ].

^ self.

It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ]

simple thing feels practical and nice :)

On Sun, Jan 4, 2015 at 3:13 PM, Benoit St-Jean <bstjean@yahoo.com> wrote:

In Object, it should return false, not self!

No. Look at Seb's original implementation: Object>>ifNilOrEmpty: aBlock self ifNil: [ ^ aBlock value ]. (self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ]. ^ self. The first statement moves to UndefinedObject>>ifNilOrEmpty: aBlock ^aBlock value The second to e.g. Collection>>ifNilOrEmpty: aBlock ^self isEmpty ifTrue: [aBlock value] ifFalse: [self] leaving just Object>>ifNilOrEmpty: aBlock ^self The idea is that in "var := self thing ifNilOrEmpty: [blah]" var gets "self thing" if not nil or empty.

----------------- Benoit St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean IRC: lamneth

Blogue: endormitoire.wordpress.com

"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

------------------------------ *From:* Sebastian Sastre <sebastian@flowingconcept.com> *To:* Benoit St-Jean <bstjean@yahoo.com>; Pharo Development List < pharo-dev@lists.pharo.org> *Sent:* Sunday, January 4, 2015 6:06 PM *Subject:* Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

but not putting it on Object would change the feature since you *do want it* returning self on that case.

But from your comment we can take the idea of adding it in Object, UndefinedObject and Collection and it will be a faster implementation since it will be trivial for the three of them, no?

On Jan 4, 2015, at 8:40 PM, Benoit St-Jean <bstjean@yahoo.com> wrote:

A cleaner implementation would be to define this method in UndefinedObject and Collection only. It should not appear in Object, the same way #isEmptyOrNil is defined.

----------------- Benoit St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean IRC: lamneth Blogue: endormitoire.wordpress.com

"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

------------------------------ *From:* Sebastian Sastre <sebastian@flowingconcept.com> *To:* Pharo Development List <pharo-dev@lists.pharo.org> *Sent:* Sunday, January 4, 2015 5:27 PM *Subject:* [Pharo-dev] Object>>ifNilOrEmpty: aBlock

Hi guys,

I’ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

self ifNil: [ ^ aBlock value ].

(self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ].

^ self.

It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ]

simple thing feels practical and nice :)

-- best, Eliot

On Jan 5, 2015, at 12:07 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

...

On 05 Jan 2015, at 12:06 , Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote:

but not putting it on Object would change the feature since you do want it returning self on that case.

No. In that case, you want to use ifNil: , not ifNilOrEmpty:. The only thing Object >> ifNilOrEmpty would support, is putting both collections and non-collection in the same variable, which is usually a bad idea to begin with, since it will lead to "are you a collection or single instance?" checks in almost every user of said variable.

Hi Henry, I think you are talking of a different feature or maybe promoting that things should not be treated as possibly nil or empty collections which is understandable but I’m treating the programers as good citizens that know what they do and bear the consequences (not as beasts that should be educated or indoctrinated or prevented on how to use code and do things) Whatever the case does your idea pass this test? testIfNilOrEmpty | stuff thing | stuff := nil. self assert: stuff equals: nil. self assert: thing equals: nil. thing := stuff ifNilOrEmpty: [ 42 ]. self assert: thing equals: 42. stuff := 1984. thing := stuff ifNilOrEmpty: [ 42 ]. self deny: thing = nil. self assert: thing equals: 1984. self deny: thing = 42.

Ah Henry but you are making the code to know if it’s a collection or not, I talking about making the code specifically to ignore that. Why that would lead to "bad code"? can you elaborate or put examples instead of adjectives?

On Jan 5, 2015, at 1:02 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

No, I'm talking about exactly what I quoted, implementing ifNilOrEmpty: on just UndefinedObject/Collection, but not Object. Doing that is not about indoctrinating, but preventing bad code resulting from using the same variable to hold non-polymorphic objects.

...

Whatever the case does your idea pass this test?

testIfNilOrEmpty

| stuff thing |

stuff := nil.

self assert: stuff equals: nil. self assert: thing equals: nil. thing := stuff ifNilOrEmpty: [ 42 ]. self assert: thing equals: 42.

stuff := 1984. thing := stuff ifNilOrEmpty: [ 42 ].

self deny: thing = nil. self assert: thing equals: 1984. self deny: thing = 42.

Of course, since my idea was to use ifNil: when the variable you are dealing with is not Collections.

On Jan 5, 2015, at 1:48 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

...

On 05 Jan 2015, at 4:20 , Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote:

Ah Henry but you are making the code to know if it’s a collection or not, I talking about making the code specifically to ignore that.

Why that would lead to "bad code"? can you elaborate or put examples instead of adjectives?

I did that already:

I took a look at the thread and I don’t see examples of bad code I’m still curious about what you mean by that

On 05 Jan 2015, at 5:37 , Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

...

On 05 Jan 2015, at 5:07 , Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote:

...

On Jan 5, 2015, at 1:48 PM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote:

...

On 05 Jan 2015, at 4:20 , Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote:

Ah Henry but you are making the code to know if it’s a collection or not, I talking about making the code specifically to ignore that.

Why that would lead to "bad code"? can you elaborate or put examples instead of adjectives?

I did that already:

I took a look at the thread and I don’t see examples of bad code

I’m still curious about what you mean by that

Are you joking? I quoted the elaboration on what I mean by bad code...

Cheers, Henry

Just in case there's something weird with your mail client, it was: "it will lead to "are you a collection or single instance?" checks in almost every user of said variable." Which is unneccessary pain compared to using a collection with a single entry if that's what you mean instead, and have all users expect a collection of items to deal with. So you'd do: stuff: aCollection stuff := aCollection ifNilOrEmpty: ["Default collection" #(1 2 3)] which will raise an error if you pass in, say, Object new as pishPosh, instead of leaving each user of stuff to determine whether stuff is a collection, an object, or nil. Of course, you can still do nonsense like stuff := aCollection ifNilOrEmpty: [42] but at least *that* problem is easier to pinpoint when later, a debugger with a user of stuff that expected it to be a collection pops up. If the origin of stuff as a single instance is lost to the mists of time (say, Object implements ifNilOrEmpty: and someone called stuff: with an Object without error), it's easier to end up with a solution of "fixing" the use to (stuff isKindOf: Collection) "or is that isCollection?" ifTrue: ["Code handling each entry"] ifFalse: ["Code handling single instance"] And now there's two stinks. Cheers, Henry

...

Hi Henry,

I think you are talking of a different feature or maybe promoting that things should not be treated as possibly nil or empty collections which is understandable but I’m treating the programers as good citizens that know what they do and bear the consequences (not as beasts that should be educated or indoctrinated or prevented on how to use code and do things)

No, I'm talking about exactly what I quoted, implementing ifNilOrEmpty: on just UndefinedObject/Collection, but not Object. Doing that is not about indoctrinating, but preventing bad code resulting from using the same variable to hold non-polymorphic objects.

I thought the same :) Thanks Henry I love your view on the world.

This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection. A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty. Cheers, Doru On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

taste is taste but would you care to illustrate your point with examples? I’m curious about it

...

On Jan 5, 2015, at 6:12 AM, stepharo <stepharo@free.fr> wrote:

You summarise well the kind of code I do not like. isNil everywhere and horrible tests.

Stef

Le 4/1/15 23:27, Sebastian Sastre a écrit :

...

Hi guys,

I’ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

self ifNil: [ ^ aBlock value ].

(self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ].

^ self.

It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ]

simple thing feels practical and nice :)

-- www.tudorgirba.com "Every thing has its own flow"

On Jan 5, 2015, at 10:38 AM, phil@highoctane.be wrote:

In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though).

Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners).

We could use

x := [ self thing ] ifError: [ someDefault ]

I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string)

for these purposes. Triggering errors is not too nice still.

Now, what if self itself is nil or empty?

BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name?

Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah] `self thing` could be an expensive process that returns something or nil or an empty collection. If you get nil or empty as result then you would get the block values resulting in having blah at someVar

In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent.

What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion.

how can you do that one-liner without introducing ifNilOrEmpty: ?

Phil

On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection.

A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty.

Cheers, Doru

On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it

...

On Jan 5, 2015, at 6:12 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

You summarise well the kind of code I do not like. isNil everywhere and horrible tests.

Stef

Le 4/1/15 23:27, Sebastian Sastre a écrit :

...

Hi guys,

I’ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

self ifNil: [ ^ aBlock value ].

(self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ].

^ self.

It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ]

simple thing feels practical and nice :)

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

-- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be <mailto:Mail%3Aphil@highoctane.be> | Web: http://philippeback.eu <http://philippeback.eu/> Blog: http://philippeback.be <http://philippeback.be/> | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos <http://www.youtube.com/user/philippeback/videos>

High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/ <http://consortium.pharo.org/> Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com <http://spamcast.libsyn.com/> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

I dont know javascript well nor pharo but I am coming from python and for this scenario it would make more sense to me to use an exception than an actual check. At least that is the way Python deals with this situation which is an approach I really like. I know Pharo has exception handling as well, but unlike Python where exception handling is very popular I have barely seen it used by pharo coders. I am curious why . On Mon, Jan 5, 2015 at 3:01 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

On Jan 5, 2015, at 10:38 AM, phil@highoctane.be wrote:

In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though).

Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners).

We could use

x := [ self thing ] ifError: [ someDefault ]

I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string)

for these purposes. Triggering errors is not too nice still.

Now, what if self itself is nil or empty?

BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name?

Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah]

`self thing` could be an expensive process that returns something or nil or an empty collection. *If* you get nil or empty as result then you would get the block values resulting in having blah at someVar

In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent.

What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion.

how can you do that one-liner without introducing *ifNilOrEmpty:* ?

Phil

On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection.

A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty.

Cheers, Doru

On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

...

taste is taste but would you care to illustrate your point with examples? I’m curious about it

...

On Jan 5, 2015, at 6:12 AM, stepharo <stepharo@free.fr> wrote:

You summarise well the kind of code I do not like. isNil everywhere and horrible tests.

Stef

Le 4/1/15 23:27, Sebastian Sastre a écrit :

...

Hi guys,

I’ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

self ifNil: [ ^ aBlock value ].

(self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ].

^ self.

It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ]

simple thing feels practical and nice :)

-- www.tudorgirba.com

"Every thing has its own flow"

-- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos

High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

I see , very interesting I will definitely take a look because obviously this something I want to use too . On Mon, Jan 5, 2015 at 3:44 PM, phil@highoctane.be <phil@highoctane.be> wrote:

Exception handling is used a lot.

Check senders of #on:do:

457 in my Pharo 3.0

That's not counting the 303 #ensure: that are used transparently in things like:

aFileRef readStreamDo: [ :s | s upToEnd ]

Phil

On Mon, Jan 5, 2015 at 2:12 PM, kilon alios <kilon.alios@gmail.com> wrote:

...

I dont know javascript well nor pharo but I am coming from python and for this scenario it would make more sense to me to use an exception than an actual check. At least that is the way Python deals with this situation which is an approach I really like.

I know Pharo has exception handling as well, but unlike Python where exception handling is very popular I have barely seen it used by pharo coders. I am curious why .

On Mon, Jan 5, 2015 at 3:01 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

...

On Jan 5, 2015, at 10:38 AM, phil@highoctane.be wrote:

In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though).

Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners).

We could use

x := [ self thing ] ifError: [ someDefault ]

I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string)

for these purposes. Triggering errors is not too nice still.

Now, what if self itself is nil or empty?

BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name?

Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah]

`self thing` could be an expensive process that returns something or nil or an empty collection. *If* you get nil or empty as result then you would get the block values resulting in having blah at someVar

In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent.

What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion.

how can you do that one-liner without introducing *ifNilOrEmpty:* ?

Phil

On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection.

A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty.

Cheers, Doru

On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

...

taste is taste but would you care to illustrate your point with examples? I’m curious about it

...

On Jan 5, 2015, at 6:12 AM, stepharo <stepharo@free.fr> wrote:

You summarise well the kind of code I do not like. isNil everywhere and horrible tests.

Stef

Le 4/1/15 23:27, Sebastian Sastre a écrit :

...

Hi guys,

I’ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

self ifNil: [ ^ aBlock value ].

(self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ].

^ self.

It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ]

simple thing feels practical and nice :)

-- www.tudorgirba.com

"Every thing has its own flow"

one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string. Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection. About #thing being meaningless, sure, I’ve mentioned as general example. I don’t see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) Thanks for giving it a thought

On Jan 5, 2015, at 11:14 AM, Norbert Hartl <norbert@hartl.name> wrote:

...

Am 05.01.2015 um 14:01 schrieb Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>>:

...

On Jan 5, 2015, at 10:38 AM, phil@highoctane.be <mailto:phil@highoctane.be> wrote:

In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though).

Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners).

...

We could use

x := [ self thing ] ifError: [ someDefault ]

I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string)

...

for these purposes. Triggering errors is not too nice still.

Now, what if self itself is nil or empty?

BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name?

Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah]

`self thing` could be an expensive process that returns something or nil or an empty collection. If you get nil or empty as result then you would get the block values resulting in having blah at someVar

...

In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent.

What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion.

how can you do that one-liner without introducing ifNilOrEmpty: ?

What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way.

my 2 cents,

norbert

...

...

Phil

On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection.

A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty.

Cheers, Doru

On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it

...

On Jan 5, 2015, at 6:12 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

You summarise well the kind of code I do not like. isNil everywhere and horrible tests.

Stef

Le 4/1/15 23:27, Sebastian Sastre a écrit :

...

Hi guys,

I’ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

self ifNil: [ ^ aBlock value ].

(self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ].

^ self.

It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ]

simple thing feels practical and nice :)

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

-- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be <mailto:Mail%3Aphil@highoctane.be> | Web: http://philippeback.eu <http://philippeback.eu/> Blog: http://philippeback.be <http://philippeback.be/> | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos <http://www.youtube.com/user/philippeback/videos>

High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/ <http://consortium.pharo.org/> Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com <http://spamcast.libsyn.com/> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

El Mon Jan 05 2015 at 10:50:48 AM, phil@highoctane.be <phil@highoctane.be> escribió:

Why not put that into a Trait?

TDefaultValueIdiom>>ifEmptyOrNil: aDefaultObject

So, if wanted,, one can put "uses TDefaultValueIdiom" (I am at a loss for a great name here, help!) and do as Sebastian proposes.

This will prevent pollution of Object while at the same time being able to have the idiom available (and maybe with more than one form).

But you can't "hot plug" a Trait to Object to have this behavior system-wide. Adding a trait involves recompilation AFAIR. The only thing I'd argue against is the naming. Otherwise is a very convenient method, when you go outside of the Smalltalk island and interact with API's not very well crafted or desgned to err on the "safe" side (empty collections instead o null), asking whether an object isNull or empty in the same method is really convenient. If we get purists, nil shouldn't exist either [1] and they should be replaced by domain specific abstractions representing the void/undefined. But we know there is a use case for nil, as IMO, there is a use case for isEmptyOrNil. However, whether you add it to Object in Pharo core image or not isn't really relevant, whoever wants/needs it can add it afterwards. Regards, [1] http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistak...

Am 05.01.2015 um 14:43 schrieb Sebastian Sastre <sebastian@flowingconcept.com>:

one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string.

Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection.

About #thing being meaningless, sure, I’ve mentioned as general example. I don’t see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :)

My point is that as long as you do not promise a certain type of object you will have to deal with the uncertainty what methods you can call on that object of uncertain type. By not using a check you just extend the life of this uncertainty a while longer (bad if the user of your code has to deal with it). Some has to deal with it if the object has to do something. And the earlier this uncertainty is removed the better it is. At least in my opinion. Norbert

Thanks for giving it a thought

...

On Jan 5, 2015, at 11:14 AM, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:

...

Am 05.01.2015 um 14:01 schrieb Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>>:

...

On Jan 5, 2015, at 10:38 AM, phil@highoctane.be <mailto:phil@highoctane.be> wrote:

In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though).

Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners).

...

We could use

x := [ self thing ] ifError: [ someDefault ]

I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string)

...

for these purposes. Triggering errors is not too nice still.

Now, what if self itself is nil or empty?

BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name?

Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah]

`self thing` could be an expensive process that returns something or nil or an empty collection. If you get nil or empty as result then you would get the block values resulting in having blah at someVar

...

In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent.

What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion.

how can you do that one-liner without introducing ifNilOrEmpty: ?

What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way.

my 2 cents,

norbert

...

...

Phil

On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection.

A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty.

Cheers, Doru

On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it

...

On Jan 5, 2015, at 6:12 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

You summarise well the kind of code I do not like. isNil everywhere and horrible tests.

Stef

Le 4/1/15 23:27, Sebastian Sastre a écrit :

...

Hi guys,

I’ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

self ifNil: [ ^ aBlock value ].

(self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ].

^ self.

It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ]

simple thing feels practical and nice :)

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

-- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be <mailto:Mail%3Aphil@highoctane.be> | Web: http://philippeback.eu <http://philippeback.eu/> Blog: http://philippeback.be <http://philippeback.be/> | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos <http://www.youtube.com/user/philippeback/videos>

High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/ <http://consortium.pharo.org/> Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com <http://spamcast.libsyn.com/> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Am 05.01.2015 um 15:22 schrieb Sebastian Sastre <sebastian@flowingconcept.com>:

...

On Jan 5, 2015, at 12:00 PM, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:

...

Am 05.01.2015 um 14:43 schrieb Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>>:

one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string.

Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection.

About #thing being meaningless, sure, I’ve mentioned as general example. I don’t see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :)

My point is that as long as you do not promise a certain type of object you will have to deal with the uncertainty what methods you can call on that object of uncertain type. By not using a check you just extend the life of this uncertainty a while longer (bad if the user of your code has to deal with it). Some has to deal with it if the object has to do something. And the earlier this uncertainty is removed the better it is. At least in my opinion.

Norbert

Ah! I understand your point better now, thanks for clarifying. Actually you helped me to understand better something I systematically do often which is extending that uncertainty as much as is convenient :)

For example Mapless <http://sebastianconcept.github.io/Mapless> (and MiniMapless <https://github.com/flow-stack/MiniMapless>) gives you the freedom of not having to predict what instance variables your persistent objects will have and still gives you the features now.

Is the opposite of the predictive certainty demanded by typed technologies and their the compiler is your friend BS that completely frustrates your creative flow.

Dynamic technologies are all about delaying certainty. Late binding is delaying it until runtime. I don’t say this as a technicality, I see it as a useful tool to push the present into the future and pull the future into the present.

I think I need to be more clear on this. With type I meant a set of methods I can call on an object. You can name it protocol or interface or duck type. With certainty I meant that a method #thing has to give a promise about a certain type (it returns) so you know what you can call on that object. Without knowing the type you can only invoke the set of methods defined in Object or you can use objects as structs. To build objects that serve a specific purpose you need to establish communication ways (methods and calls) that exceed that. It's all about communication after all. So I would say you need to establish certainty at coding time (using interfaces and objects). Late binding postpones the specific implementation of your type that make it possible to have plenty of use cases managed. Norbert

Being able to reflect in real-time makes this possible.

Is what makes easier to invent the future when they “touch" each other.

If someone else has to deal with the object and code with this uncertainty, you know you’re on the right place for personal mastery <http://www.cs.virginia.edu/~cs655/readings/smalltalk.html> to happen since Smalltalk was designed to allow the individual to easily navigate code and master the system by itself.

This is actually a major reason to choose Smalltalk.

Thanks again!

Of course. If you know what you are doing you will not abuse it and it will not be a recipe for disaster. You can also make recipes for disaster putting globals in Smalltalk, abusing #become: nesting ifTrue: etc etc etc which is stuff that is already there decades ago The shared convenience is for who feels it convenient. That usually happens when you have to deal with APIs which design that are out of your control and you use it to normalize it conveniently (AKA in a cheap one-liner hence this method)

On Jan 5, 2015, at 4:36 PM, stepharo <stepharo@free.fr> wrote:

Guys

Do you think that Pharo does not have the complexity of a real app? :) Now seriously if you have to deal with external values, then this is the job of the importer to import and put polymorphic default in variable. Putting nil or emtpy collection in a collection is a recipe to disaster. All clients will have to check and you can avoid that simply. Put an empty collection.

This is not because some people may not know how to program in other languages that we should copy that.

Stef

Le 5/1/15 14:01, Sebastian Sastre a écrit :

...

...

On Jan 5, 2015, at 10:38 AM, phil@highoctane.be <mailto:phil@highoctane.be> wrote:

In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though).

Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners).

...

We could use

x := [ self thing ] ifError: [ someDefault ]

I understand you’re setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string)

...

for these purposes. Triggering errors is not too nice still.

Now, what if self itself is nil or empty?

BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name?

Note that is not a testing method, it’s a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah]

`self thing` could be an expensive process that returns something or nil or an empty collection. If you get nil or empty as result then you would get the block values resulting in having blah at someVar

...

In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent.

What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion.

how can you do that one-liner without introducing ifNilOrEmpty: ?

...

Phil

On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection.

A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty.

Cheers, Doru

On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: taste is taste but would you care to illustrate your point with examples? I’m curious about it

...

On Jan 5, 2015, at 6:12 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

You summarise well the kind of code I do not like. isNil everywhere and horrible tests.

Stef

Le 4/1/15 23:27, Sebastian Sastre a écrit :

...

Hi guys,

I’ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

self ifNil: [ ^ aBlock value ].

(self isCollection and: [ self isEmpty ]) ifTrue: [ ^ aBlock value ].

^ self.

It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ‘some default value for when this.thing is undefined, null or an empty string’.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ‘some default value for when self thing is nil or an empty string’ ]

simple thing feels practical and nice :)

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

-- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be <mailto:Mail%3Aphil@highoctane.be> | Web: http://philippeback.eu <http://philippeback.eu/> Blog: http://philippeback.be <http://philippeback.be/> | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos <http://www.youtube.com/user/philippeback/videos>

High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/ <http://consortium.pharo.org/> Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com <http://spamcast.libsyn.com/> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it was removed from Object and I don’t know why, but is still in Collection and in UndefinedObject). So, in case of adding it, the correct implementation should be: 1) restore Object>>#isEmptyOrNil ^ false 2) implement: Object>>#ifEmptyOrNil: aBlock self isEmptyOrNil ifTrue: aBlock. ^ self which IMO is the clean way to implement such idiom. said that, I will go back to my vacations :) Esteban

On 05 Jan 2015, at 15:47, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

El Mon Jan 05 2015 at 3:36:50 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> escribió:

This is not because some people may not know how to program in other languages that we should copy that.

I share your "taste" for this kind of code.

But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it.

To make both "sides" of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these "language" extensions.

Regards!

probably, but in any case it has to be implemented using existing idioms, not repeating code, which was the core of my point. crap. I really need to turn off my computer or I will continue watching mails ;) Esteban

On 05 Jan 2015, at 17:25, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

As discussed in this thread, I do not see a reason for implementing this method in Object.

Having it in Collection/UndefinedObject can make some sense (although I do not really like it) for working with variables that can be either collection or nil.

Cheers, Doru

On Mon, Jan 5, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it was removed from Object and I don’t know why, but is still in Collection and in UndefinedObject). So, in case of adding it, the correct implementation should be:

1) restore Object>>#isEmptyOrNil ^ false 2) implement:

Object>>#ifEmptyOrNil: aBlock self isEmptyOrNil ifTrue: aBlock. ^ self

which IMO is the clean way to implement such idiom.

said that, I will go back to my vacations :)

Esteban

...

On 05 Jan 2015, at 15:47, Esteban A. Maringolo <emaringolo@gmail.com <mailto:emaringolo@gmail.com>> wrote:

El Mon Jan 05 2015 at 3:36:50 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> escribió:

This is not because some people may not know how to program in other languages that we should copy that.

I share your "taste" for this kind of code.

But this purist approach raises the bar leaving out a lot of developers with poor design/modelling skills. The more 1:1 mappings they can bring in from their previous language of choice, the better, and higher the odds they'll clinge on Pharo and continue using it.

To make both "sides" of this discussion happy I think the base image shouldn't include this, and there can be an extra package with these "language" extensions.

Regards!

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

On Jan 5, 2015, at 10:19 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection.

A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty.

Cheers, Doru

ok, why?