an elegant way to return a result
Hi guys, what is the best way to express the following :return (something aMsg) if it is not nil, return somethingElse elsewhere I could stil write: something aMsg     ifNil:[^ something aMsg]    ifNotNil:[^aNotherResult] but it sounds a little bit weird Regards. Abdelghani
No need to have both if you are returning the receiver. ^ something aMsg ifNotNil: [ aNotherResult ] For example try printing these two lines 1 ifNotNil: [ true ]. "true" nil ifNotNil: [ true ]. "nil" If you are interested in the implementation details I highly recommend to look at the implementation. ProtoObject>>ifNotNil: aBlock and UndefinedObject>>ifNotNil: aBlock. Peter On Tue, Jun 30, 2015 at 1:21 PM, abdelghani ALIDRA <alidrandco@yahoo.fr> wrote:
Hi guys,
what is the best way to express the following : return (something aMsg) if it is not nil, return somethingElse elsewhere
I could stil write:
something aMsg ifNil:[^ something aMsg] ifNotNil:[^aNotherResult]
but it sounds a little bit weird
Regards.
Abdelghani
Thanks eveybody, ^ something aMsg ifNotNil: [ aNotherResult ]is much more prety indded :) Abdelghani De : Peter Uhnák <i.uhnak@gmail.com> à: abdelghani ALIDRA <alidrandco@yahoo.fr>; Any question about pharo is welcome <pharo-users@lists.pharo.org> Envoyé le : Mardi 30 juin 2015 13h26 Objet : Re: [Pharo-users] an elegant way to return a result No need to have both if you are returning the receiver. ^ something aMsg ifNotNil: [ aNotherResult ] For example try printing these two lines1 ifNotNil: [ true ]. "true"nil ifNotNil: [ true ]. "nil" If you are interested in the implementation details I highly recommend to look at the implementation.ProtoObject>>ifNotNil: aBlockandUndefinedObject>>ifNotNil: aBlock. Peter On Tue, Jun 30, 2015 at 1:21 PM, abdelghani ALIDRA <alidrandco@yahoo.fr> wrote: Hi guys, what is the best way to express the following :return (something aMsg) if it is not nil, return somethingElse elsewhere I could stil write: something aMsg     ifNil:[^ something aMsg]    ifNotNil:[^aNotherResult] but it sounds a little bit weird Regards. Abdelghani
all is valid and a matter of style. You can also do this: ^ something aMsg ifNotNil:[ aNotherResult ] ifNil:[ something aMsg ] or this: something aMsg ifNil:[ ^ something aMsg ]. ^ aNotherResult cheers, Esteban
On 30 Jun 2015, at 13:21, abdelghani ALIDRA <alidrandco@yahoo.fr> wrote:
Hi guys,
what is the best way to express the following : return (something aMsg) if it is not nil, return somethingElse elsewhere
I could stil write:
something aMsg ifNil:[^ something aMsg] ifNotNil:[^aNotherResult]
but it sounds a little bit weird
Regards.
Abdelghani
Ah, C'mon Esteban! This one is not a question of style:
something aMsg ifNil:[ ^ something aMsg ]. ^ aNotherResult What the heck ... ??? ;-))))
Sorry, I couldn't resist ;-) See you in Brescia! Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Make sense if there's code in between. something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult Peter
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between. not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Yeah, that should be >something aMsg ifNil: [ ^ nil ]< I thought you were referring to something else originally. :) On Tue, Jun 30, 2015 at 1:43 PM, jtuchel@objektfabrik.de < jtuchel@objektfabrik.de> wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between.
not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
ah yeah :) I assumed first "something aMsg" ~= second "something aMsgâ In case is the same, the correct way is as you say: ^ something aMsg ifNil: [ anotherResult ] (sorry, he :P)
On 30 Jun 2015, at 13:43, jtuchel@objektfabrik.de wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between. not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Ah, Okay, you are mentioning the one and only one case in which this could make sense.... ;-) Something like stream next ifNil: [^stream next]. So there may be cases where the two sends do not return the same result. But that is, of course, not what the OP suggested. Nevertheless, I was too fast in criticizing ;-) I would consider code like that "less easy" to maintain, however. Nice thinking Kata ;-) Joachim Am 30.06.15 um 14:22 schrieb Esteban Lorenzano:
ah yeah :)
I assumed
first "something aMsg" ~= second "something aMsgâ
In case is the same, the correct way is as you say:
^ something aMsg ifNil: [ anotherResult ]
(sorry, he :P)
On 30 Jun 2015, at 13:43, jtuchel@objektfabrik.de wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between. not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Le 30/6/15 14:39, jtuchel@objektfabrik.de a écrit :
Ah, Okay, you are mentioning the one and only one case in which this could make sense.... ;-)
Something like
stream next ifNil: [^stream next].
so ugly. Please we should not teach how to do exception with blocks :)
So there may be cases where the two sends do not return the same result. But that is, of course, not what the OP suggested. Nevertheless, I was too fast in criticizing ;-)
I would consider code like that "less easy" to maintain, however.
Nice thinking Kata ;-)
Joachim
Am 30.06.15 um 14:22 schrieb Esteban Lorenzano:
ah yeah :)
I assumed
first "something aMsg" ~= second "something aMsgâ
In case is the same, the correct way is as you say:
^ something aMsg ifNil: [ anotherResult ]
(sorry, he :P)
On 30 Jun 2015, at 13:43, jtuchel@objektfabrik.de wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between. not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Stef, you're shooting the wrong man! ;-) The crime was committed in your team ;-)))) See you in Brescia Joachim Am 30.06.15 um 19:19 schrieb stepharo:
Le 30/6/15 14:39, jtuchel@objektfabrik.de a écrit :
Ah, Okay, you are mentioning the one and only one case in which this could make sense.... ;-)
Something like
stream next ifNil: [^stream next].
so ugly. Please we should not teach how to do exception with blocks :)
So there may be cases where the two sends do not return the same result. But that is, of course, not what the OP suggested. Nevertheless, I was too fast in criticizing ;-)
I would consider code like that "less easy" to maintain, however.
Nice thinking Kata ;-)
Joachim
Am 30.06.15 um 14:22 schrieb Esteban Lorenzano:
ah yeah :)
I assumed
first "something aMsg" ~= second "something aMsgâ
In case is the same, the correct way is as you say:
^ something aMsg ifNil: [ anotherResult ]
(sorry, he :P)
On 30 Jun 2015, at 13:43, jtuchel@objektfabrik.de wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between. not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- -----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
I know :D Le 1/7/15 15:19, jtuchel@objektfabrik.de a écrit :
Stef,
you're shooting the wrong man! ;-) The crime was committed in your team ;-))))
See you in Brescia
Joachim
Am 30.06.15 um 19:19 schrieb stepharo:
Le 30/6/15 14:39, jtuchel@objektfabrik.de a écrit :
Ah, Okay, you are mentioning the one and only one case in which this could make sense.... ;-)
Something like
stream next ifNil: [^stream next].
so ugly. Please we should not teach how to do exception with blocks :)
So there may be cases where the two sends do not return the same result. But that is, of course, not what the OP suggested. Nevertheless, I was too fast in criticizing ;-)
I would consider code like that "less easy" to maintain, however.
Nice thinking Kata ;-)
Joachim
Am 30.06.15 um 14:22 schrieb Esteban Lorenzano:
ah yeah :)
I assumed
first "something aMsg" ~= second "something aMsgâ
In case is the same, the correct way is as you say:
^ something aMsg ifNil: [ anotherResult ]
(sorry, he :P)
On 30 Jun 2015, at 13:43, jtuchel@objektfabrik.de wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between. not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- -----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
This whole conversation really makes me want to ask: How do you know if some code is bad, good or completely ugly ? I've not been programming for long but I've already heard sentences like this: "Damn this piece of code is so bad !" so often that I am really wondering. What are the rules ? Performant code makes total sense but it seems there is something else. Le 1 juil. 2015 23:36, "stepharo" <stepharo@free.fr> a écrit :
I know :D
Le 1/7/15 15:19, jtuchel@objektfabrik.de a écrit :
Stef,
you're shooting the wrong man! ;-) The crime was committed in your team ;-))))
See you in Brescia
Joachim
Am 30.06.15 um 19:19 schrieb stepharo:
Le 30/6/15 14:39, jtuchel@objektfabrik.de a écrit :
Ah, Okay, you are mentioning the one and only one case in which this could make sense.... ;-)
Something like
stream next ifNil: [^stream next].
so ugly. Please we should not teach how to do exception with blocks :)
So there may be cases where the two sends do not return the same result. But that is, of course, not what the OP suggested. Nevertheless, I was too fast in criticizing ;-)
I would consider code like that "less easy" to maintain, however.
Nice thinking Kata ;-)
Joachim
Am 30.06.15 um 14:22 schrieb Esteban Lorenzano:
ah yeah :)
I assumed
first "something aMsg" ~= second "something aMsgâ
In case is the same, the correct way is as you say:
^ something aMsg ifNil: [ anotherResult ]
(sorry, he :P)
On 30 Jun 2015, at 13:43, jtuchel@objektfabrik.de wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between.
not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!"
"much more code" ^ aNotherResult
Peter
-- -----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Hi matthieu on my side: stream next ifNil: [^stream next]. When you execute a block (far away from the place it was created), it acts as an exception, it stops the execution of currently executed methods and return to its home context (method that led to the creation of the block) Read deep into Pharo because this is a great chapter. So people should avoid to put return statement into a block since a block returns already the value of its last expression. So for me arg: [ ^ ... ] is a big warning. Stef Le 1/7/15 23:55, Matthieu Lacaton a écrit :
This whole conversation really makes me want to ask: How do you know if some code is bad, good or completely ugly ? I've not been programming for long but I've already heard sentences like this: "Damn this piece of code is so bad !" so often that I am really wondering. What are the rules ? Performant code makes total sense but it seems there is something else.
Le 1 juil. 2015 23:36, "stepharo" <stepharo@free.fr <mailto:stepharo@free.fr>> a écrit :
I know :D
Le 1/7/15 15:19, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> a écrit :
Stef,
you're shooting the wrong man! ;-) The crime was committed in your team ;-))))
See you in Brescia
Joachim
Am 30.06.15 um 19:19 schrieb stepharo:
Le 30/6/15 14:39, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> a écrit :
Ah, Okay, you are mentioning the one and only one case in which this could make sense.... ;-)
Something like
stream next ifNil: [^stream next].
so ugly. Please we should not teach how to do exception with blocks :)
So there may be cases where the two sends do not return the same result. But that is, of course, not what the OP suggested. Nevertheless, I was too fast in criticizing ;-)
I would consider code like that "less easy" to maintain, however.
Nice thinking Kata ;-)
Joachim
Am 30.06.15 um 14:22 schrieb Esteban Lorenzano:
ah yeah :)
I assumed
first "something aMsg" ~= second "something aMsgâ
In case is the same, the correct way is as you say:
^ something aMsg ifNil: [ anotherResult ]
(sorry, he :P)
On 30 Jun 2015, at 13:43, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between.
not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- -----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 <tel:%2B49%207141%2056%2010%2086%200> Fax: +49 7141 56 10 86 1 <tel:%2B49%207141%2056%2010%2086%201>
On Fri, Jul 3, 2015 at 5:23 AM, stepharo <stepharo@free.fr> wrote:
Hi matthieu
on my side:
stream next ifNil: [^stream next].
When you execute a block (far away from the place it was created), it acts as an exception, it stops the execution of currently executed methods and return to its home context (method that led to the creation of the block) Read deep into Pharo because this is a great chapter. So people should avoid to put return statement into a block since a block returns already the value of its last expression.
So for me arg: [ ^ ... ]
is a big warning.
Stef
Is there a code critic for that ? :) cheers -ben
Stef, So we're finding more and more problems in just a single line of code ;-) Do you see advantages in this piece of code? Would it be friendlier to the Compiler/VM or a programmer in your opinion? |nextOrNextAfterNext| nextOrNextAfterNext := stream next ifNil: [stream next]. ^nextOrNextAfterNext Joachim Am 02.07.15 um 23:23 schrieb stepharo:
Hi matthieu
on my side:
stream next ifNil: [^stream next].
When you execute a block (far away from the place it was created), it acts as an exception, it stops the execution of currently executed methods and return to its home context (method that led to the creation of the block) Read deep into Pharo because this is a great chapter. So people should avoid to put return statement into a block since a block returns already the value of its last expression.
So for me arg: [ ^ ... ]
is a big warning.
Stef
Le 1/7/15 23:55, Matthieu Lacaton a écrit :
This whole conversation really makes me want to ask: How do you know if some code is bad, good or completely ugly ? I've not been programming for long but I've already heard sentences like this: "Damn this piece of code is so bad !" so often that I am really wondering. What are the rules ? Performant code makes total sense but it seems there is something else.
Le 1 juil. 2015 23:36, "stepharo" <stepharo@free.fr <mailto:stepharo@free.fr>> a écrit :
I know :D
Le 1/7/15 15:19, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> a écrit :
Stef,
you're shooting the wrong man! ;-) The crime was committed in your team ;-))))
See you in Brescia
Joachim
Am 30.06.15 um 19:19 schrieb stepharo:
Le 30/6/15 14:39, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> a écrit :
Ah, Okay, you are mentioning the one and only one case in which this could make sense.... ;-)
Something like
stream next ifNil: [^stream next].
so ugly. Please we should not teach how to do exception with blocks :)
So there may be cases where the two sends do not return the same result. But that is, of course, not what the OP suggested. Nevertheless, I was too fast in criticizing ;-)
I would consider code like that "less easy" to maintain, however.
Nice thinking Kata ;-)
Joachim
Am 30.06.15 um 14:22 schrieb Esteban Lorenzano:
ah yeah :)
I assumed
first "something aMsg" ~= second "something aMsgâ
In case is the same, the correct way is as you say:
^ something aMsg ifNil: [ anotherResult ]
(sorry, he :P)
On 30 Jun 2015, at 13:43, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between.
not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- -----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 <tel:%2B49%207141%2056%2010%2086%200> Fax: +49 7141 56 10 86 1 <tel:%2B49%207141%2056%2010%2086%201>
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
by the way
nextOrNextAfterNext := stream next ifNil: [stream next].
I would argue that almost every person who would read this would think it's a bug and it should be ifNotNil: Also there would be no point in saving it to a variable if you will just return. ^ stream next ifNil: [ stream next ]
Well, thanks for the documentation, the first article was quite interesting and I'm gonna get this book asap :) When you execute a block (far away from the place it was created), it acts
as an exception, it stops the execution of currently executed methods and return to its home context (method that led to the creation of the block) Read deep into Pharo because this is a great chapter. So people should avoid to put return statement into a block since a block returns already the value of its last expression.
So for me
arg: [ ^ ... ]
is a big warning.
Thanks for the explanation, I need to read this chapter, right :p By the way, I've always used return statements in blocks to "break" out of loops since i didn't find any "break" method in Pharo. Is that bad too ? 2015-07-03 10:11 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
by the way
nextOrNextAfterNext := stream next ifNil: [stream next].
I would argue that almost every person who would read this would think it's a bug and it should be ifNotNil:
Also there would be no point in saving it to a variable if you will just return. ^ stream next ifNil: [ stream next ]
By the way, I've always used return statements in blocks to "break" out of loops since i didn't find any "break" method in Pharo. Is that bad too ?
It's still the same thing. Could you provide an example where you do such a thing? When I started with Smalltalk I had also this habit of forcing loops everywhere and breaking them, and only later I realized that it is very often much better expressed as collections with do:/select:/collect:/... Peter
Le 3/7/15 12:17, Peter Uhnák a écrit :
By the way, I've always used return statements in blocks to "break" out of loops since i didn't find any "break" method in Pharo. Is that bad too ?
It's still the same thing. Could you provide an example where you do such a thing? When I started with Smalltalk I had also this habit of forcing loops everywhere and breaking them, and only later I realized that it is very often much better expressed as collections with do:/select:/collect:/...
yes but internally this is what they do
Peter
Le 3/7/15 11:53, Matthieu Lacaton a écrit :
Well, thanks for the documentation, the first article was quite interesting and I'm gonna get this book asap :)
When you execute a block (far away from the place it was created), it acts as an exception, it stops the execution of currently executed methods and return to its home context (method that led to the creation of the block) Read deep into Pharo because this is a great chapter. So people should avoid to put return statement into a block since a block returns already the value of its last expression.
So for me arg: [ ^ ... ]
is a big warning.
Thanks for the explanation, I need to read this chapter, right :p
By the way, I've always used return statements in blocks to "break" out of loops since i didn't find any "break" method in Pharo. Is that bad too ?
no this correct. ifTrue: [^ self and other] is a natural pattern I tend to do ^ ,.,.,. ifTrue: ifFalse: instead of ,mm.,. ifTrue: ^ ifFalse: ^ because I prefer and in VW this is was creating easier to optimise blocks Now the wrong pattern is hhhh foo: [^ self] where foo: is not a defined control flow because here you really mean. I want to get back here. and this is different from hhhh foo: [ self ]
2015-07-03 10:11 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
by the way
nextOrNextAfterNext := stream next ifNil: [stream next].
I would argue that almost every person who would read this would think it's a bug and it should be ifNotNil:
Also there would be no point in saving it to a variable if you will just return. ^ stream next ifNil: [ stream next ]
Le 3/7/15 09:09, jtuchel@objektfabrik.de a écrit :
Stef,
So we're finding more and more problems in just a single line of code ;-)
Do you see advantages in this piece of code? Would it be friendlier to the Compiler/VM or a programmer in your opinion? yes :)
|nextOrNextAfterNext|
nextOrNextAfterNext := stream next ifNil: [stream next]. ^nextOrNextAfterNext
Joachim
Am 02.07.15 um 23:23 schrieb stepharo:
Hi matthieu
on my side:
stream next ifNil: [^stream next].
When you execute a block (far away from the place it was created), it acts as an exception, it stops the execution of currently executed methods and return to its home context (method that led to the creation of the block) Read deep into Pharo because this is a great chapter. So people should avoid to put return statement into a block since a block returns already the value of its last expression.
So for me arg: [ ^ ... ]
is a big warning.
Stef
Le 1/7/15 23:55, Matthieu Lacaton a écrit :
This whole conversation really makes me want to ask: How do you know if some code is bad, good or completely ugly ? I've not been programming for long but I've already heard sentences like this: "Damn this piece of code is so bad !" so often that I am really wondering. What are the rules ? Performant code makes total sense but it seems there is something else.
Le 1 juil. 2015 23:36, "stepharo" <stepharo@free.fr <mailto:stepharo@free.fr>> a écrit :
I know :D
Le 1/7/15 15:19, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> a écrit :
Stef,
you're shooting the wrong man! ;-) The crime was committed in your team ;-))))
See you in Brescia
Joachim
Am 30.06.15 um 19:19 schrieb stepharo:
Le 30/6/15 14:39, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> a écrit :
Ah, Okay, you are mentioning the one and only one case in which this could make sense.... ;-)
Something like
stream next ifNil: [^stream next].
so ugly. Please we should not teach how to do exception with blocks :)
So there may be cases where the two sends do not return the same result. But that is, of course, not what the OP suggested. Nevertheless, I was too fast in criticizing ;-)
I would consider code like that "less easy" to maintain, however.
Nice thinking Kata ;-)
Joachim
Am 30.06.15 um 14:22 schrieb Esteban Lorenzano:
ah yeah :)
I assumed
first "something aMsg" ~= second "something aMsgâ
In case is the same, the correct way is as you say:
^ something aMsg ifNil: [ anotherResult ]
(sorry, he :P)
On 30 Jun 2015, at 13:43, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> wrote:
Am 30.06.15 um 13:40 schrieb Peter Uhnák:
Make sense if there's code in between.
not sure what you're saying. I mean, sending the message twice makes sense if you already know the outcome? Hmmm...
something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" "much more code" ^ aNotherResult
Peter
-- -----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 <tel:%2B49%207141%2056%2010%2086%200> Fax: +49 7141 56 10 86 1 <tel:%2B49%207141%2056%2010%2086%201>
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchelmailto:jtuchel@objektfabrik.de Fliederweg 1http://www.objektfabrik.de D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
On 30 Jun 2015, at 1:21 , abdelghani ALIDRA <alidrandco@yahoo.fr> wrote:
Hi guys,
what is the best way to express the following : return (something aMsg) if it is not nil, return somethingElse elsewhere
I could stil write:
something aMsg ifNil:[^ something aMsg] ifNotNil:[^aNotherResult]
but it sounds a little bit weird
Regards.
Abdelghani
Assuming there's a bug in your code, and not the stated intent, the normal way is: ^something aMsg ifNil: [anotherResult] Cheers, Henry
participants (8)
-
abdelghani ALIDRA -
Ben Coman -
Esteban Lorenzano -
Henrik Johansen -
jtuchel＠objektfabrik.de -
Matthieu Lacaton -
Peter Uhnák -
stepharo