What about something like
{|x| x == x.to_i.to_s}
If the string the above block is applied to is not a number, this
should fail, right?
-Rich
On Thu, 22 Dec 2005 14:53:54 -0000, [email protected] wrote:
end
end
begin
obj.meth
rescue NoMethodError
endor some variant thereof. (Obviously in true duck-typing cases you
just send the message without this kind of check, but there are cases
where the check makes sense.)
Good point. Now you mention that, I think I’d probably end up going for
the latter style in that case anyway, despite my comments earlier about
exceptions. I guess it’s about a balance between being prepared for
exceptions and pre-empting them. Mostly in Java (the only language I’ve
really used exceptions with) the choice is made, since you have to deal
with (so-called ‘checked’) exceptions whenever they might be thrown, so
I’m still finding my balance there.
I expect that version also makes refactoring easier later on if you
decide
to move the further up the chain.
I’ve toyed with the idea of some kind of special “nack” object that
would be returned on these kinds of method calls, but I don’t think it
plays well with method_missing.
As a general way for objects to nack method calls? If so, maybe the
default method_missing (or equivalent?) could do that, or you can
provide
your own method_missing to do whatever…?
The implications of the metaprogramming stuff on thread safety is a
subject that, frankly, worries me. When I understand a bit more I’m
looking forward to investigating that side of things.
Cheers,
Hi –
On Fri, 23 Dec 2005, Joel VanderWerf wrote:
[email protected] wrote:
begin
obj.meth
rescue NoMethodError
end
[Did I really indent by only 1? It must have been early in the
morning… :-]
This has the unfortunate side effect of conflating NoMethodErrors that
are reported for other method calls besides the original obj.meth but
which occur during that method. What’s the best way of handling that?
Compare exception.backtrace depth with the current backtrace depth?
I guess, but it gets awfully cluttered. I don’t know what the best
way is. Too bad exceptions don’t have a depth property or
something…
It’s not really threadsafe either. By the time is
executed, #meth could have been defined (though you do know it was
undefined at the time of the method call, which is an improvement over
the #respond_to version).
I guess in a sense anything non-atomic is non-threadsafe, but here at
least you know there won’t be a fault-line between knowing whether the
object responds to the message, and asking it to do so. The method
call happens all at once, and then everything else sort of falls away
from that.
David
–
David A. Black
[email protected]
“Ruby for Rails”, from Manning Publications, coming April 2006!
On 12/22/05, [email protected] [email protected] wrote:
On Fri, 23 Dec 2005, Joel VanderWerf wrote:
This has the unfortunate side effect of conflating NoMethodErrors that
are reported for other method calls besides the original obj.meth but
which occur during that method. What’s the best way of handling that?
Compare exception.backtrace depth with the current backtrace depth?I guess, but it gets awfully cluttered. I don’t know what the best
way is. Too bad exceptions don’t have a depth property or
something…
How about something like this:
class Exception
def self.local
primary = self
localized = Class.new
klass = (class << localized; self; end)
klass.send(:define_method, :===) do |other|
primary === other and other.depth == 1
end
localized
end
def depth
self.backtrace.length
end
end
Usage:
begin
bar()
rescue NoMethodError.local => e
end
def bar
foo()
end
begin
bar()
rescue NoMethodError.local => e
end
First rescue catches the undefined bar since it’s local, second rescue
doesn’t catch the undefined foo since it’s not local.
Jacob F.
First, thanks all very much for the lively discussion thus far. It’s
proven very useful.
Timothy H. wrote:
The Integer() method raises ArgumentError if given an empty,
non-numeric, or otherwise non-well-formed string.
Hmm…apparently not–at least not w/ 1.8.2 on mswin32.
This:
begin
one, two = ARGV.map{ |n| Integer(n) }
rescue ArgumentError
puts “Usage…”
exit
end
puts one
puts two
Outputs:
nil
nil
When fed no command-line arguments. It does work as intended if any of
the args are non-empty strings, however.
Also:
raise “Hey, ‘#{ arg }’ needs to be a number” if !arg.match(/^\d*$/)
I’m a regexp neophyte, without skill or clue. Any suggestions on
tutorials?
Thanks,
-Matthew
On Thu, 22 Dec 2005 18:47:04 -0000, Matthew F.
[email protected]
wrote:
I’m a regexp neophyte, without skill or clue. Any suggestions on
tutorials?
One I’ve used:
http://www.regular-expressions.info/tutorial.html
It’s not specific to any language.
Rich wrote:
What about something like
{|x| x == x.to_i.to_s}
If the string the above block is applied to is not a number, this
should fail, right?
It will fail for “012” as well.
Matthew F. wrote:
puts two
Outputs:
nil
nilWhen fed no command-line arguments. It does work as intended if any of
the args are non-empty strings, however.
That would be because Integer is never called. If there are no
command-line arguments, ARGV is empty, there’s nothing to map.
On 12/22/05, Matthew F. [email protected] wrote:
Outputs:
I’m a regexp neophyte, without skill or clue. Any suggestions on
tutorials?
Dunno about tutorials, but:
the / characters indidicate that whatever is between them is a regular
expression.
^ is the beginning of a line (or string)
\d is a digit (i.e. 0 1 2 3 4 5 6 7 8 or 9)
- means to match 0 or more of the previous thing.
$ is the end of the line.
So, /^\d*$/ means that the entire string from beginning to end is
comprised of zero or more digits. So, a minus sign (‘-’) or any
non-digit somewhere in the string would fail the check.
Timothy H. wrote:
That would be because Integer is never called. If there are no
command-line arguments, ARGV is empty, there’s nothing to map.
That makes perfect sense. Thanks.
So, after some experimentation I’ve got the code listed below. It
successfully checks for:
1.) an empty ARGV (i.e., no command-line args)
2.) more than 2 arguments
3.) non-numeric arguments
4.) negative arguments
5.) first arg greater than second arg
Which is to say, it does everything I want it to. However, I wonder if
it can be optimized, condensed?
Here be code:
$usage = “Usage”
def print_usage val
if val==“exit”
print $usage
exit
else
print $usage
end
end
if ARGV!=[] and !(ARGV.length > 2)
begin
arg0, arg1 = ARGV.map{ |n| Integer(n) }
if (arg0 < 0) or (arg1 < 0)
print_usage(“exit”)
elsif arg0>arg1
print_usage(“exit”)
end
rescue ArgumentError
print_usage(“exit”)
end
else
print_usage(“exit”)
end
Matthew F. wrote:
Which is to say, it does everything I want it to. However, I wonder if
it can be optimized, condensed?
How 'bout corrected first? Guess my last post is a perfect argument in
favor of my learning how to use test units.
Corrected code be here:
$usage = “Usage:”
def print_usage(val)
if val==“exit”
print $usage
exit
else
print $usage
end
end
if ARGV!=[] and !(ARGV.length > 2)
begin
arg0, arg1 = ARGV.map{ |n| Integer(n) }
if (arg0 < 0) or (!arg1.nil? and (arg1 < 0))
print_usage(“exit”)
elsif !arg1.nil? and (arg0 > arg1)
print_usage(“exit”)
end
rescue ArgumentError
print_usage(“exit”)
end
else
print_usage(“exit”)
end
def read_arguments
arg0, arg1 = ARGV.map{ |n| Integer(n) }
raise ArgumentError if arg0.nil? or arg0 < 0
raise ArgumentError if arg1.nil? or arg1 < 0
raise ArgumentError if arg0 > arg1
return arg0, arg1
rescue ArgumentError
print <<-USAGE
Usage
USAGE
exit
end
a, b = read_arguments
Jacob F.
Jacob F. wrote:
def read_arguments
arg0, arg1 = ARGV.map{ |n| Integer(n) }
raise ArgumentError if arg0.nil? or arg0 < 0
raise ArgumentError if arg1.nil? or arg1 < 0
raise ArgumentError if arg0 > arg1
return arg0, arg1
rescue ArgumentError
print <<-USAGE
Usage
USAGE
exit
enda, b = read_arguments
Very nice. I like this construction. However, I believe the above will
throw the exception when I have only one valid arg, which is not what I
want (1 or 2 args is correct; no more, no less).
So, it should look like this, yes?
def read_arguments
arg0, arg1 = ARGV.map{ |n| Integer(n) }
raise ArgumentError if (ARGV.length == 0) or (ARGV.length > 2)
raise ArgumentError if (arg0 < 0) or (!arg1.nil? and (arg1 < 0))
raise ArgumentError if !arg1.nil? and (arg0 > arg1)
return arg0, arg1
rescue ArgumentError
print <<-USAGE
Usage
USAGE
exit
end
a, b = read_arguments
On 12/22/05, Matthew F. [email protected] wrote:
USAGE
exit
enda, b = read_arguments
Write the damn tests, man! 
If it passes the tests, it should work, unless you have faulty tests,
in which case you need more/better tests.