Which messages objects shall respond to? (was: syntactic sugar buzz)

[Robert Dober]

hi here I am again

my original (simplified question was): Why Nil#to_i and not Nil#split.
Generally why X#a and not X#b?

Well that's pretty much all, actually there are quite some ways to
look at this, but I shall learn and not teach, so I will just be
silent for once

All comments are appreciated.

Robert

 

[Stefan Rusterholz]

hi here I am again

my original (simplified question was): Why Nil#to_i and not Nil#split.
Generally why X#a and not X#b?

Well that's pretty much all, actually there are quite some ways to
look at this, but I shall learn and not teach, so I will just be
silent for once

All comments are appreciated.

Robert

I'd like Nil only to respond to the same methods as Object does.
That said, I'd not have anything against a special syntax to say "go on
unless the value is nil"
E.g.
# this will raise if gets returns nil
while line = gets.chomp

# just returns nil
while line = gets->chomp

I.e. while . would work normally, -> would stop the method chain as soon
as the receiver is nil and just return nil.
Unlike a Nil responding to everything and just returning nil again, this
one would leave the coder in control as to specify where he actually
wants to know immediatly if he has a nil and where he doesn't want to
know because the result is the same.
I don't know how difficult that would be to implement, though.

Regards
Stefan

 

[dblack]

Hi --

hi here I am again

my original (simplified question was): Why Nil#to_i and not Nil#split.
Generally why X#a and not X#b?

I don't think there's a general answer; each case is going to be
different. In the case of Nil#to_i and Nil#split, I think the
difference is something like this:

#split suggests that nil has the property of "being composite" (i.e.,
it is something that can split). #to_i, however, just means that nil
has been assigned an arbitrary integer representation. It doesn't
mean that nil has any particular properties.


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Robert Dober]

Hi --



I don't think there's a general answer; each case is going to be
different. In the case of Nil#to_i and Nil#split, I think the
difference is something like this:

#split suggests that nil has the property of "being composite" (i.e.,
it is something that can split). #to_i, however, just means that nil
has been assigned an arbitrary integer representation. It doesn't
mean that nil has any particular properties.

I have thought about a different approach,
what are the chances that the #to_i message is sent to nil by purpose
and what are the chances that it is done by error.
I would weight usefulness against purity ( and consistency for that matter ).

I simply thought and still think that chances that somebody uses
nil#to_i on purpose are at least as slim as that somebody sends split
to nil, and only now I complain about inconsistency. Obviously that
was not clear at all.

Another example, what are the chances that Hash#map returning an array
is more useful than returning it a hash. I have complained about this
"inconsistency" not because it is an inconsistency, but because I feel
it is an useless, counter productive inconsistency.

Yet another example, is it useful that the following is not
implemented in standard Ruby

class Symbol
include Comparable
def <=> other; to_s <=> other.to_s end
end

I feel these are questions that can be discussed in order to make Ruby
advance, I am sure that Matz weights CRCs much more serious if there
has been discussions like these here...

Pitty if we miss these chances..


Side note:
I just guess that the usage of the word inconsistency has been a bad
error of my part, but is it not clear from my strange English that I
am not a native speaker ???
Yes you can say: "What, Really, You are not a native speaker, amaaaazing"

David

Robert

 

[Martin DeMello]

Another example, what are the chances that Hash#map returning an array
is more useful than returning it a hash. I have complained about this
"inconsistency" not because it is an inconsistency, but because I feel
it is an useless, counter productive inconsistency.

Side effect of #map being defined generically in Enumerable, though I
agree that a "structural" map would be more useful for a lot of data
structures.

martin

 

[Robert Dober]

Side effect of #map being defined generically in Enumerable,

that is a good point, it is indeed well documented , which is
important in theses contexts

though I
agree that a "structural" map would be more useful for a lot of data
structures.

Anyway that is the level of discussion I find more useful

Robert