alias_method :tap, :affect

[Josh Susser]

Ruby's enumeration message names come directly from its Smalltalk
ancestry. There are also some aliases. Like so:

*method* *alias*
collect map
detect find
select find_all
reject
inject

Ruby 1.9 introduces the K-combinator in the form of the method
Object#tap. I don't get the name #tap at all. So I'm proposing a new
name/alias pair, with a more meaningful name:

*method* *alias*
affect tap

"foo".affect { |s| s << "bar" }
#=> "foobar"

The K-combinator is all about side-effecting the receiver object, so
"affect" seems like a meaningful name for that functionality (whereas
"effect" would be wrong!). "tap" is still cute, and rhymes with "map",
so having both seems like a good Rubyish way to go.

Thoughts?

 

[Rick DeNatale]

Ruby's enumeration message names come directly from its Smalltalk
ancestry. There are also some aliases. Like so:

*method* *alias*
collect map
detect find
select find_all
reject
inject

Ruby 1.9 introduces the K-combinator in the form of the method
Object#tap. I don't get the name #tap at all. So I'm proposing a new
name/alias pair, with a more meaningful name:

*method* *alias*
affect tap

"foo".affect { |s| s << "bar" }
#=> "foobar"

The K-combinator is all about side-effecting the receiver object, so
"affect" seems like a meaningful name for that functionality (whereas
"effect" would be wrong!). "tap" is still cute, and rhymes with "map",
so having both seems like a good Rubyish way to go.

Of course, active-support also defines the same method as Object#returning

I'm not sure how the Smalltalk intro ties in here. I can't recall a
method implementation of the k-combinator in common use in Smalltalk,
in most cases the message cascade syntax ending with an invocation of
#yourself, would serve the cases where the k-combinator is used:

Ruby

a = MyObject.new.tap do |o| # or returning, or affect
o.foo = 1
o.bar = "whatever"
end

Smalltalk
a = MyObject.new foo: 1;
bar: "whatever";
yourself

For Rubyists unfamiliar with Smalltalk, the message cascade triggered
by the ; meant send the message after the ; to the receiver of the
last message. Object#yourself was defined to return the receiver, and
was not typically overridden.

 

[Josh Susser]

Of course, active-support also defines the same method as
Object#returning

Not exatcly. #tap works on the receiver, #returning works on an
argument. #tap is more object-oriented IMO.

returning("foo") { |s| s << "bar" }
"foo".affect { |s| s << "bar" }

I'm not sure how the Smalltalk intro ties in here.

It's just to say how awsome methods that end in "ect" are, and why

I can't recall a
method implementation of the k-combinator in common use in Smalltalk,
in most cases the message cascade syntax ending with an invocation of
#yourself, would serve the cases where the k-combinator is used:

Ruby

a = MyObject.new.tap do |o| # or returning, or affect
o.foo = 1
o.bar = "whatever"
end

Smalltalk
a = MyObject.new foo: 1;
bar: "whatever";
yourself

For Rubyists unfamiliar with Smalltalk, the message cascade triggered
by the ; meant send the message after the ; to the receiver of the
last message. Object#yourself was defined to return the receiver, and
was not typically overridden.

That's exactly right. Cascaded messages were cool, and came right out of
the stack machine nature of Smalltalk's bytecodes. And I've often longed
for a #yourself method in Ruby, but usually only to get to the target of
a proxy object.

 

[furtive.clown]

This is the first I've heard of Object#tap. It seems backward because
you almost always want the result of the block, not the object back
again. All of my ruby scripts use

class Object
def as
yield self
end
end

E.g, a recent script of mine does

platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.as { |t|
t + audio_basenames
}.map { |f|
File.join(audio_dir, f)
}

I know this could be written

platform_audio_files = (audio_stems.map { |f|
f + "." + audio_ext[platform]
} + audio_basenames).map { |f|
File.join(audio_dir, f)
}

but I find that uncouth compared to the former.

If ruby is adding anything, it should be the behavior of Object#as,
not Object#tap.

 

[ara.t.howard]

a = MyObject.new.tap do |o| # or returning, or affect
o.foo = 1
o.bar = "whatever"
end

just as easy to do this though:

a = MyObject.new.instance_eval{
foo 1
bar 'whatever'
self
}

no special methods needed...

returning is, imho, over rated.

cheers.

a @ http://codeforpeople.com/

 

[furtive.clown]

It would seem Object#tap is for the imperative style and Object#as is
for the functional style. My ruby code is always improved ---
clearer, smaller, more elegant --- when I use a functional style as
much as possible. For example cutting down on side-effects and being
in the mindset of chaining results rather than re-assigning to the
same variable. Please, if you add Object#tap then you must add its
functional equivalent Object#as (call it what you wish).

 

[Martin DeMello]

This is the first I've heard of Object#tap. It seems backward because
you almost always want the result of the block, not the object back
again.

#tap is the opposite use case - you want to "tap" the object stream,
observing without affecting. It's very handy for debugging, where you
can tap into a chain of method calls, print something out and continue
on your way, e.g.

foo.map(&:bar).tap {|a| p a}.inject...

martin

 

[Yossef Mendelssohn]

Ruby's enumeration message names come directly from its Smalltalk
ancestry. There are also some aliases. Like so:

*method* *alias*
collect map
detect find
select find_all
reject
inject

Ruby 1.9 introduces the K-combinator in the form of the method
Object#tap. I don't get the name #tap at all. So I'm proposing a new
name/alias pair, with a more meaningful name:

*method* *alias*
affect tap

"foo".affect { |s| s << "bar" }
#=> "foobar"

The K-combinator is all about side-effecting the receiver object, so
"affect" seems like a meaningful name for that functionality (whereas
"effect" would be wrong!). "tap" is still cute, and rhymes with "map",
so having both seems like a good Rubyish way to go.

Thoughts?

I remember some of this talk from RubyConf IRC, and I'm still not
convinced about "affect". Personally, I would expect a method called
"affect" to return the receiver with some change, whereas tap returns
the receiver as-is. Your example modifies the receiver in place, so
it's a little confounding.

MenTaLguY has yet to chime in, so I'll beat him to the punch with his
own link. http://moonbase.rydia.net/mental/blog/programming/eavesdropping-on-expressions
has some examples of what Object#tap is (possibly) intended for, and
that makes the name perfectly sensible, as far as I'm concerned. It's
for "tapping into" the line of calls, allowing you to see what's going
on at that point, but not changing anything.

Don't get me wrong, though. I'm all for more methods that end in
"ect".

I also find tap and returning to be for completely different purposes.
The point of the latter is mainly to get away from things like

def some_method
var = ''
some_stuff_with(var)
var += something_else
var.more_things
var
end

and instead let you write something like

def some_method
var = ''
returning(var) do |x|
some_stuff_with(x)
x += something_else
x.more_things
end
end
[/QUOTE]

 

[Josh Susser]

#tap is the opposite use case - you want to "tap" the object stream,
observing without affecting. It's very handy for debugging, where you
can tap into a chain of method calls, print something out and continue
on your way, e.g.

foo.map(&:bar).tap {|a| p a}.inject...

martin

That's a great example of a use-case for #tap. (I think I remember that
from the original discussion of the feature.) But the K-combinator style
side-effect is valid too. Just look at all the uses of #returning in
Rails.

 

[furtive.clown]

#tap is the opposite use case - you want to "tap" the object stream,
observing without affecting.

OK I understand Object#tap now. At first I thought the motivation was
to modify the object inside the block, but now I see that it can be a
useful part of functional-style ruby.

So, to throw this out again --- there should also be Object#as which
returns the block result (I like the name 'as' but I am not
particularly attached to it). I can personally attest to its
usefulness, and I can show reams of examples in addition to the above
one I gave.

 

[James Edward Gray II]

So, to throw this out again --- there should also be Object#as which
returns the block result (I like the name 'as' but I am not
particularly attached to it). I can personally attest to its
usefulness, and I can show reams of examples in addition to the above
one I gave.

I guess I want to see some more examples, because I'm seriously
doubting the usefulness. The example you showed so far was using it
to create this:

platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.as { |t|
t + audio_basenames
}.map { |f|
File.join(audio_dir, f)
}

instead of:

platform_audio_files = (audio_stems.map { |f|
f + "." + audio_ext[platform]
} + audio_basenames).map { |f|
File.join(audio_dir, f)
}

I don't really understand what the problem is with the second version
that's shorter and easier for me to understand. If it's the need to
introduce some parentheses into the call chain, we can fix that:

platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.concat(audio_basenames).map { |f|
File.join(audio_dir, f)
}

So yes, please send more examples as I remain unconvinced.

James Edward Gray II

 

[Robert Dober]

This is the first I've heard of Object#tap. It seems backward because
you almost always want the result of the block, not the object back
again. All of my ruby scripts use

class Object
def as
yield self
end
end

I am so glad, I really needed Object#itself in Labrador, somehow I
felt alone with this approach, now it seems i am not that weird after
all.

I however adhere with Ara's POV, what is there that instance_eval
cannot give you?

Cheers
Robert

E.g, a recent script of mine does

platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.as { |t|
t + audio_basenames
}.map { |f|
File.join(audio_dir, f)
}

I know this could be written

platform_audio_files = (audio_stems.map { |f|
f + "." + audio_ext[platform]
} + audio_basenames).map { |f|
File.join(audio_dir, f)
}

but I find that uncouth compared to the former.

If ruby is adding anything, it should be the behavior of Object#as,
not Object#tap.

 

[Joel VanderWerf]

just as easy to do this though:

a = MyObject.new.instance_eval{
foo 1
bar 'whatever'
self
}

no special methods needed...

returning is, imho, over rated.

Really?

There is the scope issue. I use this construct sometimes:

def socket
@socket ||= UDPSocket.open.then do |s|
s.setsockopt(Socket::SOL_SOCKET, Socket::SO_BROADCAST, true)
s.connect(@svr_addr, @svr_port)
end
end

def initialize
@svr_addr, @svr_port = ...
end

def run
loop { socket.send(...) }
end

#instance_eval makes it unnatural to access instance variables of the
outer scope (you have to pass them through locals).

(#then is my own personal preference to #tap, which usually makes me
start thinking about Spinal Tap, and I have to laugh for a while.)

 

[furtive.clown]

On Nov 12, 2007, at 2:40 PM, (e-mail address removed) wrote:

I guess I want to see some more examples, because I'm seriously
doubting the usefulness. The example you showed so far was using it
to create this:

platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.as { |t|
t + audio_basenames
}.map { |f|
File.join(audio_dir, f)
}

instead of:

platform_audio_files = (audio_stems.map { |f|
f + "." + audio_ext[platform]
} + audio_basenames).map { |f|
File.join(audio_dir, f)
}

I don't really understand what the problem is with the second version
that's shorter and easier for me to understand. If it's the need to
introduce some parentheses into the call chain, we can fix that:

platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.concat(audio_basenames).map { |f|
File.join(audio_dir, f)
}

So yes, please send more examples as I remain unconvinced.

It was only a coincidence that you found an Array method which
corresponded to the operation in the block, namely Array#concat. Your
example breaks down once the operation is nontrivial --- something
more complex than '+'.

We can also introduce temporaries inside the block without causing
distraction in the outer scope. The purpose of the block chain is to
produce a value for platform_audio_files; a flood temporary variables
on the same scope obscures this purpose.

 

[James Edward Gray II]

On Nov 12, 2007, at 2:40 PM, (e-mail address removed) wrote:

I guess I want to see some more examples, because I'm seriously
doubting the usefulness. The example you showed so far was using it
to create this:

platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.as { |t|
t + audio_basenames
}.map { |f|
File.join(audio_dir, f)
}

instead of:

platform_audio_files = (audio_stems.map { |f|
f + "." + audio_ext[platform]
} + audio_basenames).map { |f|
File.join(audio_dir, f)
}

I don't really understand what the problem is with the second version
that's shorter and easier for me to understand. If it's the need to
introduce some parentheses into the call chain, we can fix that:

platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.concat(audio_basenames).map { |f|
File.join(audio_dir, f)
}

So yes, please send more examples as I remain unconvinced.

It was only a coincidence that you found an Array method which
corresponded to the operation in the block, namely Array#concat. Your
example breaks down once the operation is nontrivial --- something
more complex than '+'.

We can also introduce temporaries inside the block without causing
distraction in the outer scope. The purpose of the block chain is to
produce a value for platform_audio_files; a flood temporary variables
on the same scope obscures this purpose.

My counter argument would be that, if it becomes non-trivial, you're
trying to be too fancy doing it all in one call chain. Split it up
into the few lines of code it needs to be. Then, if the variables
and such become significant enough to affect the outer scope, it's
time to tuck the operation away in some method where it belongs.

James Edward Gray II

 

[furtive.clown]

I am so glad, I really needed Object#itself in Labrador, somehow I
felt alone with this approach, now it seems i am not that weird after
all.

I however adhere with Ara's POV, what is there that instance_eval
cannot give you?

Well, I don't want a block which is evaluated in the instance's
context. Why would I even risk doing that? What if I want to use the
"self" before the instance_eval? What if I use "self" inside the
block while forgetting that I'm inside an instance_eval? I'd be
screwed for no reason.

The use instance_eval communicates a specific purpose which entirely
different from the purpose of Object#as. I want to take the current
object, name it *as* something, perform some operations on it, and
give the result.

The current object should not be given the name "self", which is a
special name. It should be given a temporary name (e.g. "t") which
communicates its temporal non-specialness. Object#instance_eval is
the former, Object#as is the latter.

 

[furtive.clown]

On Nov 12, 2007, at 2:40 PM, (e-mail address removed) wrote:
I guess I want to see some more examples, because I'm seriously
doubting the usefulness. The example you showed so far was using it
to create this:
platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.as { |t|
t + audio_basenames
}.map { |f|
File.join(audio_dir, f)
}
instead of:
platform_audio_files = (audio_stems.map { |f|
f + "." + audio_ext[platform]
} + audio_basenames).map { |f|
File.join(audio_dir, f)
}
I don't really understand what the problem is with the second version
that's shorter and easier for me to understand. If it's the need to
introduce some parentheses into the call chain, we can fix that:
platform_audio_files = audio_stems.map { |f|
f + "." + audio_ext[platform]
}.concat(audio_basenames).map { |f|
File.join(audio_dir, f)
}
So yes, please send more examples as I remain unconvinced.

It was only a coincidence that you found an Array method which
corresponded to the operation in the block, namely Array#concat. Your
example breaks down once the operation is nontrivial --- something
more complex than '+'.

We can also introduce temporaries inside the block without causing
distraction in the outer scope. The purpose of the block chain is to
produce a value for platform_audio_files; a flood temporary variables
on the same scope obscures this purpose.

My counter argument would be that, if it becomes non-trivial, you're
trying to be too fancy doing it all in one call chain. Split it up
into the few lines of code it needs to be. Then, if the variables
and such become significant enough to affect the outer scope, it's
time to tuck the operation away in some method where it belongs.

If you had only one temporary variable in the block, would you move it
to a method? I would prefer to keep that temporary inside the #as
block -- it truly improves understandably and readability. There is
no confusion about what the intent is: we are interested in the
result, not the temporaries.

#as is also used to make function calls prettier:

filename = File.basename(input.map { |t|
t.gsub(re, "_")
}.join)

filename = input.map { |t|
t.gsub(re, "_")
}.join.as { |t|
File.basename(t)
}

I greatly prefer the latter. I want to chain, chain, chain, and I
don't want pesky prefix-y function calls like File.basename() to cramp
my style.

 

[James Edward Gray II]

#as is also used to make function calls prettier:

filename = File.basename(input.map { |t|
t.gsub(re, "_")
}.join)

filename = input.map { |t|
t.gsub(re, "_")
}.join.as { |t|
File.basename(t)
}

I greatly prefer the latter.

I would use:

file_name = File.basename(input.join.gsub(re, "_"))

James Edward Gray II

 

[furtive.clown]

I would use:

file_name = File.basename(input.join.gsub(re, "_"))

Not if re has \A or \Z. In any case you may be missing the point,
though.

 

[James Edward Gray II]

Not if re has \A or \Z.

If the Regexp contain such an anchor, we probably shouldn't be
calling gsub().

In any case you may be missing the point, though.

I may be, sure. As may you.

My point is that your examples aren't convincing me. Even if we have
to support the anchor, I prefer your first example. It's more
obvious to me. But I'll sleep OK tonight if we just agree to
disagree on that.

James Edward Gray II