Dynamic detection of bang and question methods

[August Lilleaas]

I got this idea of a sort of neat syntatic sugar of bang (foo!) and
question (foo?) methods. Take a look at this pastie:
http://pastie.caboo.se/98638

The idea is that you'll have two keywords added to Ruby - bang_given?
and question_given?. Similar to block_given?.

In this pastie, the method "finish" will not call save, as bang_given?
isn't true. If you call "finish!", though, b ang_given will return true,
and save will be called.

Same thing with question_given?. Question given would be the least
useful of them, though.

And yes, doing def finish!; finish; save; is pretty easy, and this is
not the sort of thing that should have max priority. It would still be a
nice addition to the code-design useability of Ruby, though, as having
10 "def finish!; finish; save;"-ish methods is pretty boring.

(And yes, looping and define_method, too, but still!)

 

[Sebastian Hungerecker]

I got this idea of a sort of neat syntatic sugar of bang (foo!) and
question (foo?) methods. Take a look at this pastie:
http://pastie.caboo.se/98638

http://pastie.caboo.se/98672
You could implement something similar for ?-methods, but I don't see the
point. If you have a method foo! you almost always have method foo that
does the same thing without changing the object - that's hardly the case
for foo? methods.


HTH,
Sebastian

 

[Rick DeNatale]

I got this idea of a sort of neat syntatic sugar of bang (foo!) and
question (foo?) methods. Take a look at this pastie:
http://pastie.caboo.se/98638

The idea is that you'll have two keywords added to Ruby - bang_given?
and question_given?. Similar to block_given?.

In this pastie, the method "finish" will not call save, as bang_given?
isn't true. If you call "finish!", though, b ang_given will return true,
and save will be called.

Same thing with question_given?. Question given would be the least
useful of them, though.

And yes, doing def finish!; finish; save; is pretty easy, and this is
not the sort of thing that should have max priority. It would still be a
nice addition to the code-design useability of Ruby, though, as having
10 "def finish!; finish; save;"-ish methods is pretty boring.

It doesn't seem to carry it's own weight so as to merit the
fundamental change to ruby semantics it implies. Ruby would need to
magically turn a finish! call into a finish call and arrange to return
true for bang_given?

If it really bothers you to write those finish! methods for YOUR
classes, why not do a little work with method_missing or a class
method to generate the pair which could be done without affecting the
language or the base classes?

For example:

shadowfax:~/Documents rick$ cat magic_bang.rb
module MagicBang

def method_missing(msg, *args, &blk)
msg.to_s.sub(/(.+)!$/) do
__send__($1, *args, &blk)
return save
end
super
end
end

class TestClass
include MagicBang

def finish
puts "Finish called"
end

def save
puts "save called"
end
end

puts "Calling finish method"
TestClass.new.finish
puts
puts "Calling finish! method"
TestClass.new.finish!
shadowfax:~/Documents rick$ ruby magic_bang.rb
Calling finish method
Finish called

 

[August Lilleaas]

shadowfax:~/Documents rick$ cat magic_bang.rb
module MagicBang

def method_missing(msg, *args, &blk)
msg.to_s.sub(/(.+)!$/) do
__send__($1, *args, &blk)
return save
end
super
end
end

I would, however, argue that bang_given? would look a lot more clean.
But then again, the effort it'll take to implement this is probably not
worth it. Would be cool, but I guess it's not useful enough.

 

[Sebastian Hungerecker]

But then again, the effort it'll take to implement this is probably not
worth it. Would be cool, but I guess it's not useful enough.

Unless there's something I'm missing, I *did* implement this and actually it
wasn't too much effort at all.