Quick: it responds, it evaluates, and is not empty

ruby-talk
21

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?

···

On Friday 17 January 2003 09:26 am, ahoward wrote:

On Fri, 17 Jan 2003 dblack@candle.superlink.net wrote:

–
tom sawyer, aka transami
transami@transami.net

22

Hi –

It can be done, but it’s not a general solution, because there might
be methods that do exist and still return nil. Thus a nil return
can’t be treated as an unambiguous synonym for not responding.

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

i believe this would maintain backwards compatibility since old code would not
distinguish between false/nil returns from respond_to? but would allow new
code to have the concept of NACK without any new classes or globals required.

This is different, though, from having the (attempted) call to the
method itself return NACK. Also, I’m not sure what the difference is
between your false and nil cases.

can someone give me a simple example of wanting a NACK though? i think this
thread has ignored the original question of how to :

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

No, respond_to?(:meth) doesn’t pertain to local variables. Also,
symbols aren’t specifically compile-time things; they can be
dynamically generated. And respond_to? can take a String too.

The idea of NACK would be to have a way to accomplish both the test
for method existence, and the actual call of the method, in one
expression, instead of having to break them out as in Tom’s example.

David

···

On Sat, 18 Jan 2003, ahoward wrote:

On Fri, 17 Jan 2003 dblack@candle.superlink.net wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

23

This is different, though, from having the (attempted) call to the method
itself return NACK.

yes. but the same thing can be accompished.

Also, I’m not sure what the difference is between your false and nil cases.

???

~ > irb
irb(main):001:0> false == nil
false
irb(main):002:0> false === nil
false

the extra ‘nil’ return from respond_to? can easily have the NACK semantic
since it is distinguishable from ‘false’.

No, respond_to?(:meth) doesn’t pertain to local variables.

hmmmm. i said ‘ameth’ pertained to local vars,not :ameth. they are different
in tom’s example.

Also, symbols aren’t specifically compile-time things; they can be
dynamically generated.

really? how? i would like to know how to do that if it is possible.

i don’t counting eval since in eval ‘:sym’ the recognition of :sym occurs at
compile time (of the string) and counting this would be like saying any
language which can generate, compile, and load code at runtime is
dynamic: like calling a C program which writes, compiles into a *.so, and
dl_opens a library ‘dynamic’.

The idea of NACK would be to have a way to accomplish both the test for
method existence, and the actual call of the method, in one expression,
instead of having to break them out as in Tom’s example.

is the issue that

begin object.meth *args; rescue NameError; end

isn’t short enough? i guess i can understand that, but hiding (by making too
concise) throwing/catching of exceptions reminds me of a certain ‘p’ language.
after working in c++ and java i feel that ruby’s exceptions are concise enough
to not be problematic, while being sufficiently verbose to stand out in code.
i think this is really a good thing because shortcuts provided to ignore
exceptions would be a little too tempting to use - and forget about - IMHO.

-a

···

On Sat, 18 Jan 2003 dblack@candle.superlink.net wrote:

–

====================================

Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================

24

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.

i see your point, but see my post to david. in general i love syntax
shortcuts, but i’m not comfortable about that because it hide exception
throwing…

yes, close but ameth can’t be local (right?) since it needs to respond. but
you got the idea.

i guessed you might have looked up ameth in a table within the method :

ameth = symtable [ :ameth ]

but no, it needn’t be local.

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?

yes.

why not simply :

def send (sym, *args)
begin; super.send sym, *args; rescue NameError; end
end

i guess you would then need to no what happened in try, thus the need for
something like the discussed NACK. i suppose i can see your point now.

what about something similar to

require ‘singleton’
module Nack
class NotAcknowledged
include Singleton
end
NACK = NotAcknowledged.instance
end
class Object # or better your class
include Nack
def method_missing (sym, *args)
return NACK
end
end

o = Object.new
p o.meth # #Nack::NotAcknowledged:0x401836bc#

i actually like that one (someone suggested it earlier). it’s short and
ignores exceptions, but it would be patently clear to anyone reading the code
that missing methods do not throw exceptions.

then you’d end up writing

if x != NACK…

lol. guess that’s what i you wanted all along. just didn’t see the whole
picture untill now! :wink:

-a

···

On Sat, 18 Jan 2003, Tom Sawyer wrote:

–

====================================

Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================

25

Hi –

This is different, though, from having the (attempted) call to the method
itself return NACK.

yes. but the same thing can be accompished.

Also, I’m not sure what the difference is between your false and nil cases.

???

~ > irb
irb(main):001:0> false == nil
false
irb(main):002:0> false === nil
false

the extra ‘nil’ return from respond_to? can easily have the NACK semantic
since it is distinguishable from ‘false’.

But then it’s unnecessary. respond_to? returning false is already the
equivalent of the NACK scenario. The gist of the NACK idea is to have
a way to do it without respond_to? – that is, to have the method call
itself return something which means the object didn’t respond.

No, respond_to?(:meth) doesn’t pertain to local variables.

hmmmm. i said ‘ameth’ pertained to local vars,not :ameth. they are different
in tom’s example.

Also, symbols aren’t specifically compile-time things; they can be
dynamically generated.

really? how? i would like to know how to do that if it is possible.

I was thinking mainly of String#intern:

$ cat sym.rb
print "String: "
sy = gets.chomp.intern
puts “Corresponding symbol is #{sy}, which is a #{sy.class}”

$ ruby sym.rb
String: blah
Corresponding symbol is blah, which is a Symbol

The idea of NACK would be to have a way to accomplish both the test for
method existence, and the actual call of the method, in one expression,
instead of having to break them out as in Tom’s example.

is the issue that

begin object.meth *args; rescue NameError; end

isn’t short enough? i guess i can understand that, but hiding (by making too
concise) throwing/catching of exceptions reminds me of a certain ‘p’ language.
after working in c++ and java i feel that ruby’s exceptions are concise enough
to not be problematic, while being sufficiently verbose to stand out in code.
i think this is really a good thing because shortcuts provided to ignore
exceptions would be a little too tempting to use - and forget about - IMHO.

In this case it’s not a matter of hiding or ignoring exceptions, but
of implementing a different (non-exception-related) way of handling
the no-method situation.

For me there are two problems with the exception-wrapping idiom:
speed, and the absence of an exception which precisely and uniquely
corresponds to “this object did not respond to that message.”
NameError can represent a case where the method got called but,
itself, tried to call a non-existent method on an object.

David

···

On Sat, 18 Jan 2003, ahoward wrote:

On Sat, 18 Jan 2003 dblack@candle.superlink.net wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

26

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.

i see your point, but see my post to david. in general i love syntax
shortcuts, but i’m not comfortable about that because it hide exception
throwing…

The point, though, is to return a nack instead of throwing an
exception. For speed, if nothing else.

i actually like that one (someone suggested it earlier). it’s short and
ignores exceptions, but it would be patently clear to anyone reading the code
that missing methods do not throw exceptions.

That was mine. The problem, though, is that anyone writing their own
method_missing has to explicitly remember to call super. I know it’d
break Ruby’s model, but there are times I think it’d be really
convenient if method_missing was treated as a special case, and behaved
more like, say, a multimethod.

martin

···

ahoward ahoward@fsl.noaa.gov wrote:

On Sat, 18 Jan 2003, Tom Sawyer wrote:

27

But then it’s unnecessary. respond_to? returning false is already the
equivalent of the NACK scenario. The gist of the NACK idea is to have a way
to do it without respond_to? – that is, to have the method call itself
return something which means the object didn’t respond.

i finally got this. too much of the coffee-beer-coffee-beer cycle…

I was thinking mainly of String#intern:

that’s at least the second time i’ve forgotten about that method. i’ve never
really understood why there cannot be

class Symbol
def initialize str
…
end
end

which i would NOT forget about…

i looked into parse.c (rb_intern) and it’s certainly looks possible…

$ cat sym.rb
print "String: "
sy = gets.chomp.intern
puts “Corresponding symbol is #{sy}, which is a #{sy.class}”

$ ruby sym.rb
String: blah
Corresponding symbol is blah, which is a Symbol

you are absolutely correct. this DOES install a new symbol in the table at
runtime. again, why no Symbol#new str i wonder?

In this case it’s not a matter of hiding or ignoring exceptions, but
of implementing a different (non-exception-related) way of handling
the no-method situation.

For me there are two problems with the exception-wrapping idiom:
speed, and the absence of an exception which precisely and uniquely
corresponds to “this object did not respond to that message.”
NameError can represent a case where the method got called but,
itself, tried to call a non-existent method on an object.

good point. but wouldn’t simply returning NACK from method missing accomplish
this? (see my other post)

-a

···

On Sat, 18 Jan 2003 dblack@candle.superlink.net wrote:

–

====================================

Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================

28

i actually like that one (someone suggested it earlier). it’s short and
ignores exceptions, but it would be patently clear to anyone reading the
code that missing methods do not throw exceptions.

i like it too, expcept too…

That was mine. The problem, though, is that anyone writing their own
method_missing has to explicitly remember to call super. I know it’d
break Ruby’s model, but there are times I think it’d be really
convenient if method_missing was treated as a special case, and behaved
more like, say, a multimethod.

indeed, but would super always be called first or last ?

def method_missing
#super (auto super here?)
…some code…
#super (auto super here?)
end

and what it you really needed super somewhere in between? kind of a can of
worms. it would just be much better if we had a real nack.

···

On Friday 17 January 2003 03:28 pm, Martin DeMello wrote:

–
tom sawyer, aka transami
transami@transami.net

                               .''.
   .''.      .        *''*    :_\/_:     .
  :_\/_:   _\(/_  .:.*_\/_*   : /\ :  .'.:.'.

.‘’.: /\ : ./)\ ‘:’* /\ * : ‘..’. -=:o:=-
:/:‘.:::. | ’ ‘’ * ‘.'/.’ (/’.‘:’.’
: /\ : ::::: = / -= o =- /)\ ’ *
‘..’ ‘:::’ === * /\ * .‘/.'. ‘._____
* | .. : |. |’ .—"|
* | _ .–’| || | _| |
* | .-‘| __ | | | || |
.-----. | |’ | || | | | | | || |
__’ ’ /“\ | '-.”". ‘-’ ‘-.’ '` |.

29

I don’t entirely disagree, but “welcome to the world of exception
handling!”

Something within me rejects the notion that code should be designed to
call random methods and handle the case where they don’t exist. But
I’ve been surprised many times by the clever and unique things that
people make Ruby do, and I’m eager to be surprised again.

e.g. I’ve been fascinated beyond belief reading about mock objects,
and their super-elegant implementation in Ruby. Hooray for people
with more imagination than me!

Gavin

···

On Saturday, January 18, 2003, 8:35:10 AM, dblack wrote:

For me there are two problems with the exception-wrapping idiom:
speed, and the absence of an exception which precisely and uniquely
corresponds to “this object did not respond to that message.”
NameError can represent a case where the method got called but,
itself, tried to call a non-existent method on an object.

30

Hi –

that’s at least the second time i’ve forgotten about that method. i’ve never
really understood why there cannot be

class Symbol
def initialize str
…
end
end

which i would NOT forget about…

See http://www.rubygarden.com/article.php?sid=110 – there was a
(rejected) RCR for Symbol.new, with some commentary from Matz.

[I wrote:]

For me there are two problems with the exception-wrapping idiom:
speed, and the absence of an exception which precisely and uniquely
corresponds to “this object did not respond to that message.”
NameError can represent a case where the method got called but,
itself, tried to call a non-existent method on an object.

good point. but wouldn’t simply returning NACK from method missing accomplish
this? (see my other post)

Yes, I would assume it would be implemented as some kind of hook into,
and/or wrapper around, method_missing. The issues this would raise
would then have to do with minimizing impact on objects that already
have a method_missing… so I think it would have to be included or
extended into particular objects (including classes) selectively.

(And it’s probably not thread-safe, because no ideas I ever have are
thread-safe :slight_smile:

Here’s my latest iteration, based on code posted in this thread and my
own tinkerings:

class Method
NACK = Class.new.class_eval {
require ‘singleton’
include Singleton
}.instance

module Nacker
  def method_missing(*args)
NACK
  end
end

end

Class-wide inclusion

class A
include Method::Nacker
end

Object extension

s = “abc”
s.extend(Method::Nacker)

Demo

p A.new.no_such_method == Method::NACK # true
p s.no_such_method == Method::NACK # true

David

···

On Sat, 18 Jan 2003, ahoward wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

31

Last, I’d say - by the semantics of ‘method_missing’, you’d want your
derived class to try and handle it, and kick it up the tree if it
couldn’t, in much the same way that actual method resolution works.

martin

···

Tom Sawyer transami@transami.net wrote:

On Friday 17 January 2003 03:28 pm, Martin DeMello wrote:

That was mine. The problem, though, is that anyone writing their own
method_missing has to explicitly remember to call super. I know it’d
break Ruby’s model, but there are times I think it’d be really
convenient if method_missing was treated as a special case, and behaved
more like, say, a multimethod.

indeed, but would super always be called first or last ?

32

found this useful:

class Object

def respond_with_value(sym)
return nil if not respond_to?(sym)
v = send(sym)
case v
when nil, false, 0, 0.0, ‘’, [], {}
return false
else
return v
end
end

end

···

–
tom sawyer, aka transami
transami@transami.net

                               .''.
   .''.      .        *''*    :_\/_:     .
  :_\/_:   _\(/_  .:.*_\/_*   : /\ :  .'.:.'.

.’’.: /\ : ./)\ ‘:’* /\ * : ‘…’. -=:o:=-
:/:’.:::. | ’ ‘’ * ‘.’/.’ (/’.’:’.’
: /\ : ::::: = / -= o =- /)\ ’ *
’…’ ‘:::’ === * /\ * .’/.’. ‘._____
* | … : |. |’ .—"|
* | _ .–’| || | _| |
* | .-’| __ | | | || |
.-----. | |’ | || | | | | | || |
__’ ’ /"\ | '-."". ‘-’ ‘-.’ '` |.

33

Hi –

Something within me rejects the notion that code should be designed to
call random methods and handle the case where they don’t exist. But
I’ve been surprised many times by the clever and unique things that
people make Ruby do, and I’m eager to be surprised again.

Well, “random” is a bit extreme… :slight_smile: My main focus in all of this
is to explore ways of making it easier and faster to do something
which I think is very natural for Ruby, namely to handle situations
based on the capabilities and responses of the objects present at
a given point.

In particular, I think part of the difficulty in trying to convince
people not to rely on explicit type-checking in Ruby is that there’s
no really compelling, precise alternative. The double-barreled
“respond_to?”/method-call is, well, double-barreled, and the exception
wrapper is slow and inexact.

David

···

On Sat, 18 Jan 2003, Gavin Sinclair wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

34

i have done

def Symbol. s
s.to_s.intern
end

which makes intuitive sense to me :

Symbol[‘method’] >> :method

-a

···

On Sat, 18 Jan 2003 dblack@candle.superlink.net wrote:

See http://www.rubygarden.com/article.php?sid=110 – there was a
(rejected) RCR for Symbol.new, with some commentary from Matz.

–

====================================

Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================

35

This would be more extensible if you called v.empty? and provided an
empty? mixin for each class.

martin

···

Tom Sawyer transami@transami.net wrote:

when nil, false, 0, 0.0, ‘’, , {}

36

it seems like what you are after then are dynamic interfaces, after all
wouldn’t

if object.implements? interface
…
# does it implement all of an interface

or even

if objects.implements? interface.method :sym
…
# does it implement a method from this interface, eg with same args, etc.

if they existed, would solve all of this. it’s true this is not the same as
NACK but you wouldn’t need NACK if one could tell if an object implemented
some sort of interface would you? checking if and object did implement and
interface wouldn’t really be that different from respond_to? but it would
consoldate it considerably and result in quite readable, brief code i think.

i think i am going to go back and re-read some of the interface threads, does
anyone know of any work being done to this ends? i seem to recall the main
issues were validating arity and argument types…

-a

···

On Sat, 18 Jan 2003 dblack@candle.superlink.net wrote:

Well, “random” is a bit extreme… :slight_smile: My main focus in all of this
is to explore ways of making it easier and faster to do something
which I think is very natural for Ruby, namely to handle situations
based on the capabilities and responses of the objects present at
a given point.

In particular, I think part of the difficulty in trying to convince
people not to rely on explicit type-checking in Ruby is that there’s
no really compelling, precise alternative. The double-barreled
“respond_to?”/method-call is, well, double-barreled, and the exception
wrapper is slow and inexact.

–

====================================

Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================

37

Hi –

···

On Sat, 18 Jan 2003, ahoward wrote:

On Sat, 18 Jan 2003 dblack@candle.superlink.net wrote:

See http://www.rubygarden.com/article.php?sid=110 – there was a
(rejected) RCR for Symbol.new, with some commentary from Matz.

i have done

def Symbol. s
s.to_s.intern
end

which makes intuitive sense to me :

Symbol[‘method’] >> :method

With a string maybe, but I’m not sure about generalizing it. It’s a
kind of loose fit for other objects:

Symbol[ { “one” => 1 } ] # :one1

David

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

38

Hi –

Well, “random” is a bit extreme… :slight_smile: My main focus in all of this
is to explore ways of making it easier and faster to do something
which I think is very natural for Ruby, namely to handle situations
based on the capabilities and responses of the objects present at
a given point.

In particular, I think part of the difficulty in trying to convince
people not to rely on explicit type-checking in Ruby is that there’s
no really compelling, precise alternative. The double-barreled
“respond_to?”/method-call is, well, double-barreled, and the exception
wrapper is slow and inexact.

it seems like what you are after then are dynamic interfaces, after all
wouldn’t

if object.implements? interface
…
# does it implement all of an interface

or even

if objects.implements? interface.method :sym
…
# does it implement a method from this interface, eg with same args, etc.

if they existed, would solve all of this. it’s true this is not the same as
NACK but you wouldn’t need NACK if one could tell if an object implemented
some sort of interface would you? checking if and object did implement and
interface wouldn’t really be that different from respond_to? but it would
consoldate it considerably and result in quite readable, brief code i think.

I guess, though to me conceptually and practically a NACK
implementation is a smaller, more incremental step from what I do
already in Ruby – really almost just cosmetic, just the same kind and
degree of information we have now, but handed over in a slightly
different order. I think a whole interface apparatus is probably
another order of magnitude of programming style and/or language
adjustment.

David

···

On Sun, 19 Jan 2003, ahoward wrote:

On Sat, 18 Jan 2003 dblack@candle.superlink.net wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav