Object>>ifNilOrEmpty: aBlock

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Object>>ifNilOrEmpty: aBlock

sebastianconcept@gmail.co
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 :)


Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

Benoit St-Jean
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 <[hidden email]>
To: Pharo Development List <[hidden email]>
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 :)



Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

sebastianconcept@gmail.co
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 <[hidden email]> 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 <[hidden email]>
To: Pharo Development List <[hidden email]>
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 :)




Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

Benoit St-Jean
In Object, it should return false, not self!
 
-----------------
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 <[hidden email]>
To: Benoit St-Jean <[hidden email]>; Pharo Development List <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
To: Pharo Development List <[hidden email]>
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 :)






Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

Eliot Miranda-2


On Sun, Jan 4, 2015 at 3:13 PM, Benoit St-Jean <[hidden email]> 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 <[hidden email]>
To: Benoit St-Jean <[hidden email]>; Pharo Development List <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
To: Pharo Development List <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

stepharo
In reply to this post by sebastianconcept@gmail.co
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 :)
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

sebastianconcept@gmail.co
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 <[hidden email]> 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 :)
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

Tudor Girba-2
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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

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

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

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?

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.


Phil



On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





--

"Every thing has its own flow"



--
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

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
 

Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

sebastianconcept@gmail.co
In reply to this post by Tudor Girba-2

On Jan 5, 2015, at 10:19 AM, Tudor Girba <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

sebastianconcept@gmail.co
In reply to this post by philippeback

On Jan 5, 2015, at 10:38 AM, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





--

"Every thing has its own flow"



--
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

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
 


Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

philippeback
On Mon, Jan 5, 2015 at 2:01 PM, Sebastian Sastre <[hidden email]> wrote:

On Jan 5, 2015, at 10:38 AM, [hidden email] 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: ?

I'd agree to that for the use case you mention. Implementing it as Eliot recommends looks like the way to go.

Phil 



Phil



On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





--

"Every thing has its own flow"



--
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

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
 





--
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

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
 

Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

kilon.alios
In reply to this post by sebastianconcept@gmail.co
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 <[hidden email]> wrote:

On Jan 5, 2015, at 10:38 AM, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





--

"Every thing has its own flow"



--
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

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
 



Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

NorbertHartl
In reply to this post by sebastianconcept@gmail.co

Am 05.01.2015 um 14:01 schrieb Sebastian Sastre <[hidden email]>:


On Jan 5, 2015, at 10:38 AM, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





--

"Every thing has its own flow"



--
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

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
 



Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

sebastianconcept@gmail.co
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 <[hidden email]> wrote:


Am 05.01.2015 um 14:01 schrieb Sebastian Sastre <[hidden email]>:


On Jan 5, 2015, at 10:38 AM, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





-- 

"Every thing has its own flow"



-- 
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

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

Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

philippeback
In reply to this post by kilon.alios
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 <[hidden email]> 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 <[hidden email]> wrote:

On Jan 5, 2015, at 10:38 AM, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





--

"Every thing has its own flow"









 

Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

philippeback
In reply to this post by sebastianconcept@gmail.co
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).

Phil

On Mon, Jan 5, 2015 at 2:43 PM, Sebastian Sastre <[hidden email]> wrote:
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 <[hidden email]> wrote:


Am 05.01.2015 um 14:01 schrieb Sebastian Sastre <[hidden email]>:


On Jan 5, 2015, at 10:38 AM, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





-- 

"Every thing has its own flow"



-- 
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

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



 

Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

NorbertHartl
In reply to this post by sebastianconcept@gmail.co

Am 05.01.2015 um 14:43 schrieb Sebastian Sastre <[hidden email]>:

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 <[hidden email]> wrote:


Am 05.01.2015 um 14:01 schrieb Sebastian Sastre <[hidden email]>:


On Jan 5, 2015, at 10:38 AM, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 :)
>>
>>
>>
>
>





-- 

"Every thing has its own flow"



-- 
---
Philippe Back
Visible Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

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


Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

Esteban A. Maringolo
In reply to this post by philippeback

El Mon Jan 05 2015 at 10:50:48 AM, [hidden email] <[hidden email]> 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,


Reply | Threaded
Open this post in threaded view
|

Re: Object>>ifNilOrEmpty: aBlock

Henrik Sperre Johansen
In reply to this post by sebastianconcept@gmail.co

On 05 Jan 2015, at 12:06 , Sebastian Sastre <[hidden email]> 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.

Cheers,
Henry
123