< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous (in thread)
N :the next (in thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
On Tue, Apr 23, 2013 at 12:05 PM, Michel Demazure <lists / ruby-forum.com>wrote:
> tamouse mailing lists wrote in post #1106508:
>
> > The thing I don't like about using .tap in the way sown is that it feels
> > like a side effect, but admittedly that comes from my initial belief
> > about
> > the intention of .tap. As with most things, we find new uses for things
> > that weren't originally thought of, and I find that good for the most
> > part.
>
> I often find myself using idioms like
>
> Klass.new.tap do
> ...
> end
>
That doesn't make any sense at all: there is no point in using #tap if you
do not assign the result and not use the block parameter. (Note: #tap does
not change self.) Or do you mean
Klass.new.instance_eval do
...
end
> with Klass = Hash, Array, ... , and dreaming about a shortcut to
> 'new.tap' like 'such_that', 'with', ...
>
What is it that you want to achieve? Can you please come up with a more
realistic example?
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/