Which messages objects shall respond to? (was: syntactic sug

Ruby
#1

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

#2

Robert D. wrote:

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

#3

Hi –

On Wed, 18 Jul 2007, Robert D. wrote:

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

#4

On 7/19/07, Robert D. [email protected] wrote:

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

#5

On 7/18/07, [email protected] [email protected] wrote:

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” :wink:

David
Robert

#6

On 7/18/07, Martin DeMello [email protected] wrote:

On 7/19/07, Robert D. [email protected] wrote:

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,
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 :slight_smile:

Robert