On Sat, 1 Apr 2006, firstname.lastname@example.org wrote:
me not very rubyish to be switching based on the class of an object. As I
understand it, the more conventional way to deal with potentially diverse
argument types is to use the respond_to? method. This keeps the door open
for duck typing.
i generally do use duck typing, but sometimes it is simply not
become too verbose. for example, consider a matrix class with the
m[true] #=> all data returned
m #=> all data returned
m[true] = elems #=> data along all dims set
m = elems #=> data along all dims set
m[int] #=> treat as 1d array, return elem
m[int] = elem #=> treat as 1d array, set idx to elem
m[off, len] #=> treat as 1d array, return elems off thru
m[off, len] = elem #=> treat as 1d array, set elems off thru len
m[a … b] #=> treat as 1d array, return elems in range
m[a … b] = elem #=> treat as 1d array, set elems in range to
m[n] #=> idx one matrix by another
generalize all above so multiple indices access in
m[0,1,2] #= return idx x,y,z
m[0,30..42,true] #= return column 0, rows 30 to 42, in all height
now, in case you are thinking that i’m just being difficult, this is
how the narray class works
have fun writing that with respond_to? !!
also, when working with concrete data structures (like binary output
programs) it’s often quite sufficient to have a type mapping. further
it’s sometimes critical, for instace writing the word located at
len=4 with a packed int value or sending a given sequence of bytes down
socket that a given type is used and it’s much more natural to write
def send buf, which = nil
length = which.last - which.first
raise TypeError, which.class
than something using respond_to?.
don’t get me wrong - i defintely advocate duck typing, but when the
possible input types becomes large and behaviour is different depending
that type it becomes cumbersome. this is the price we pay for not
style polymorphism. in fact, it’s very common to see the two styles
else # dunno - assume String and use in a duck type fashion
context, what would a maybe value do? Either behavior seems wrong.
i disagree - ruby (and hardware) already supports this style of logic in
harp:~ > irb
irb(main):001:0> nan = 0.0/0.0
irb(main):002:0> nan * 42
irb(main):003:0> nan * 42 + 42.0
irb(main):004:0> obj = Object.new and obj.taint
irb(main):005:0> (obj.to_s << “string”).tainted?
irb(main):006:0> (“string” << obj.to_s).tainted?
there’s no good reason, imho, why this style of logical behaviour could
part of the logical classes (TrueClass/FalseClass) and operators (and,