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

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 always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

Robert Dober 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

···

--
Posted via http://www.ruby-forum.com/.

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

···

On Wed, 18 Jul 2007, Robert Dober wrote:

--
* 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)

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.

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

···

On 7/18/07, dblack@wobblini.net <dblack@wobblini.net> wrote:

On Wed, 18 Jul 2007, Robert Dober wrote:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

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

···

On 7/19/07, Robert Dober <robert.dober@gmail.com> 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.

>
> 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

···

On 7/18/07, Martin DeMello <martindemello@gmail.com> wrote:

On 7/19/07, Robert Dober <robert.dober@gmail.com> wrote:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck