On Friday 17 January 2003 09:26 am, ahoward wrote:
> On Fri, 17 Jan 2003 dblack / candle.superlink.net wrote:
> why not add a new return value to Object::respond_to? ?
>
> eg:
>
>   case o.respond_to? :sym
>     when true
>       # o responds to this
>     when false
>       # o does not respond to this
>     when nil
>       # o does not acknowldedge this (NACK)
>   end

but this does not free one from using respond_to? i.e. instead of: if 
respond_to?(:x), one would simply say: if x != nack.

>    if self.respond_to?(:ameth)
>            if ameth
>                    if not ameth.to_s.empty?
>                            ...
>                    end
>            end
>    end
>
> which to *me* seems to read "if i respond to a symbol known at *compile
> time* then eval ameth a couple of times, where ameth may be a method call
> or local varibable but i don't really care which, and iff ameth returned
> anything other than '' then do ..." or something pretty close to this.

yes, close but ameth can't be local (right?) since it needs to respond. but 
you got the idea.
 
> this seems really from the hip : assuming this is some pretty dynamic code,
> wouldn't you have some idea, based on what is in ameth, what to do with it
> more strongly correlated to reality than whether or not self responds to
> the compile time symbol :ameth?  i think if the purpose of the above logic
> were explained and answer may arise not involving NACK at all...

the reason: the code belongs to a mixin module. ameth is an optional method 
that the mixin can use, or not. whatever ameth returns it ultimately needs to 
be a stiring, but it is not unreasonable that it would return a symbol, thus 
the to_s. for validation purposes of course i have to make sure ameth does 
not return nil, and if it resolves to an empty string after the to_s then 
it's of no use either. does that explain it?

-- 
tom sawyer, aka transami
transami / transami.net