On Wed, Oct 23, 2013 at 1:11 PM, Bob Arning <arning315 at comcast.net> wrote:
> Except that cascade is not affected by the return value...
> self foo; bar.
>
> cares not what is returned by foo.

Your example assumes the send is to self.  I was thinking of an
example where it was sent from another class:

  louisObject methodWhichReturnsNilInsteadOfSelf
    message1 ;
    message 2

can no longer be done.  Before, it could.

But, ok, you're right, it's not specifically cascading that is affected..  :)

>
> I think there was a discussion some time ago that self might not have been
> the best default return value. YMMV.
>
> Cheers,
> Bob
>
> On 10/23/13 2:05 PM, Chris Muller wrote:
>
> Either. But in general use ^self  rather than ^nil
> so that it acts the same as the implicit ^self when you drop out the end of
> a method.
>
> +1.  Senders might want to cascade.
>
> Bob Arning wrote:
>
> I prefer the first - it gets one case out of the way quickly.
>
> Cheers,
> Bob
>
> On 10/23/13 10:12 AM, Louis LaBrunda wrote:
>
> Hi,
>
> I'm about to write a method where I need to test whether to do something or
> just get out.  What is the best practices way to do this?  For example:
>
> (a = b) ifTrue: [^nil].
> *The code that does the work*
>
> or:
>
> (a = b) ifFalse: [
>     *The code that does the work*
> ].
>
> I think the second is better style but I have used both.  Generally using
> the first when *The code that does the work* is long and the second when it
> is short.
>
> Is there any speed difference between them?  I doubt it but I thought I
> would ask anyway.
>
> Lou
> -----------------------------------------------------------
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
> mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com
>
>
>
>
>
> ________________________________
>
>
>
>
>
>
>
>
>
>
>
>