Also, #then avoids the scoping nastiness of #instance_eval.
I’m not getting the semantics of “then”. Do you mean “then” as in, “I
took off my coat and then sat down”, as opposed to then in if/then?
Yes. Not much better than #tap, is it? Any ideas…? “and_then”?
“whereupon” I guess it’s hard to find a name that’s general
enough (as opposed to, say, “post_initialize”) but also expressive
enough. It does seem a slightly odd technique to me, in any case –
sort of like saying “Now I’m going to do this: this” instead of just
going to a new line and saying: “this”. I’m not sure how much of the
oddness I feel is the technique as opposed to the naming issue.
what lead me to prefer #then (== #tap) in the first place:
took off my coat and then sat down", as opposed to then in if/then?
Yes. Not much better than #tap, is it? Any ideas…? “and_then”?
“whereupon” I guess it’s hard to find a name that’s general
enough (as opposed to, say, “post_initialize”) but also expressive
enough. It does seem a slightly odd technique to me, in any case –
sort of like saying “Now I’m going to do this: this” instead of just
going to a new line and saying: “this”. I’m not sure how much of the
oddness I feel is the technique as opposed to the naming issue.
Does the following technique seem odd?
class Foo
attr_accessor :a, :b, :c
def initialize
yield self if block_given?
end
end
foo = Foo.new do |f|
f.a = 1
f.b = 2
f.c = 3
end
#then is just a way of using arbitrary classes (or factories) in this
way. Maybe the name should not emphasize the temporal (“then” or
“whereupon”); so maybe “tap” is better, or “configured_using”.
Btw, I don’t think I’ve ever used #then in more than 5 or 6 places.
Usually, I just try to define classes like Foo above.
I wonder if there’s some name that embodies the fact that the object
is going to come back from this method call. The temporal ones (then,
and_then, etc.) sound kind of self-evident (“Well, of course the next
thing happens ‘then’,” my brain says). Perhaps that was the reasoning
behind “tap”, though “tap” doesn’t communicate much to me. I’m not
sure.
#then is just a way of using arbitrary classes (or factories) in this way.
Maybe the name should not emphasize the temporal (“then” or “whereupon”); so
maybe “tap” is better, or “configured_using”.
Part of what’s odd to me about #then is that it’s not
constructor-specific. Once it’s defined you could do:
x = string.split(’,’).then do |array|
array.map! { something }
end
Bad example But that’s what I meant about not giving it too
specific a name, like “post_initialize”, since it’s not restricted to
initialization scenarios.
I wonder if there’s some name that embodies the fact that the object
is going to come back from this method call. The temporal ones (then,
and_then, etc.) sound kind of self-evident (“Well, of course the next
thing happens ‘then’,” my brain says).
Good point! I thought of “pipe” but even that doesn’t say that it
modifies and returns self. Maybe “apply”: string.split(/\s/).apply
{|i| i.pop}.whatever. Or even “modify”.
Perhaps that was the reasoning
behind “tap”, though “tap” doesn’t communicate much to me. I’m not
sure.
‘tap’ had a different intent, though - “tee off the object without
disturbing it” - even if it did the same thing in the end. So you
would typically take a.foo.bar.baz.quux… and drop in a tap,
a.foo.bar.tap {|i| puts “hi mom! this is #{i}”}.baz.quux, and take
care not to modify i destructively.
It lets me get into the line and hear what’s going on without changing
any existing behaviour. Using a proc that modifies secret is not a
good idea, just keep it for things with other types of side-effects.
There’s no way to mark the object read-only for the purposes of the
passed-in proc, is there?
I haven’t seen anything to change my mind about the other use. It just
seems pointless.