```--- Simon Kr?ger <SimonKroeger / gmx.de> wrote:

> Joel VanderWerf wrote:
>
> > Simon Kr?ger wrote:
> >
> >>>>This very useful little method is a nice thing to have in
> your
> >>>>bag-o-tricks.
> >>>
> >>>
> >>>Nice. you could even call it #then:
> >>>
> >>>class Object
> >>>  def then
> >>>    yield(self)
> >>>    self
> >>>  end
> >>>end
> >>>
> >>>#Then you could do these types of things:
> >>>a = (0..10).to_a
> >>>i = 3
> >>>p a[i.then{i+=1}]
> >>>p i
> >>>
> >>>[..snip..]
> >>
> >>
> >>But be carefull:
> >>
> >>i = 3
> >>p i.then{i+=1}
> >>p i
> >>
> >>i = [3]
> >>p i.then{i << 4}
> >>p i
> >>
> >>
> >>output:
> >>3
> >>4
> >>[3, 4]
> >>[3, 4]
> >>
> >>
> >>(perhaps this was obvious to all, except me)
> >>
> >>cheers
> >>
> >>Simon
> >
> >
> > Good point. You really have to be especially clear about
> whether you are
> >  modifying a variable binding or an object.
> >
> > i = [3]
> > p i.then{i+=[4]}   # ==> [3]
> > p i                # ==> [3, 4]
> >
>
> woohoo,
> i+=[4] creates a new array, right?!
>
> this is - lets say - 'suboptimal' in terms of speed for the
> 99.9% of cases where you do not need the old array.
> (ok, you should realy use <<, except if you use 'then' -
> I would not like to teach someone this)

This gets us into the whole destructive vs. non-destructive
argument.  << is the efficient destructive version and + is the
non-destructive create-a-new-object, less efficient, but more
flexible version.  Non-destructive methods (that return a new
object) don't have the side-effect problem and allow method
chaining in a clean way.  It is no different for this "then"
(or "post" as I had it originally) method.

____________________________________________________