From: Robert Dober <robert.dober@...>
Date: 2007-07-19T06:31:46+09:00
Subject: Re: syntactic sugar buzz

On 7/18/07, Chad Perrin <perrin@apotheon.com> wrote:
> On Thu, Jul 19, 2007 at 06:09:43AM +0900, Robert Dober wrote:
> > On 7/18/07, Chad Perrin <perrin@apotheon.com> wrote:
> > >On Wed, Jul 18, 2007 at 09:17:45PM +0900, dblack@wobblini.net wrote:
> > >>
> > >> My favorite slogan for Ruby is:
> > >>
> > >>   The triumph of balance over symmetry.
> > >>
> > >> It means, for example, that it might make sense for nil to have #to_s
> > >> -- and that it still might *not* make sense for nil to have #split.
> > >> One does not imply the other.  Every decision is made carefully, one
> > >> at a time, in the interest of the usefulness of the system overall.
> > >
> > >That makes perfect sense, since the logical way to use split would be
> > >with something like nil.to_s.split.  If you really want split to return
> > >something "useful" from nil directly, I'd say add your own split to
> > >NilClass and be done with it.
> > It makes perfect sense, but it is an example ex nihilis as I was
> > complaining about nil.to_i and Integer(nil), or am I in the wrong
> > thread (has happened to me before :()?
> >
> > >
> > >
> > >>
> > >> That's why I don't care about symmetry or consistency (which I think
> > >> in this case mean much the same thing).  We're lucky enough to have
> > >> Matz hand-crafting the language with the greatest care; I think that's
> > >> a higher-percentage prospect than a principle of uniformity :-)
> > >
> > >I care about consistency -- in a way that makes sense, of course.  I
> > >don't see how nil lacking a split() violates that.
> > Nor do I, nor did I say so, I just wanted to say, hey if nil has to_i,
> > it can have split too, that would be no big deal at all.
>
> Unless nil.split simply returned nil, like:
>   Class NilClass
>     def split
>       self
>     end
>   end
> . . . I don't see how NilClass.split could reasonably be incorporated as
> a standard part of the language.  The only other alternatives that
> spring to mind would be to return false (as though split() were a
> boolean test in this case) or to return an empty list.  I don't think
> either of those really works very well, since returning false doesn't
> bring anything new to the table and an empty list would be turning
> nothing (nil) into something (even if it's an empty something), which is
> a severely broken approach in my opinion.
>
> Unfortunately, returning nil is also a little troublesome, since split()
> is expected to return a list, but nil is definitely not a list.
>
> Maybe nil.split should just return an exception.  Oh, wait . . .
do you mean NoMethodError ;) ?
Your thoughts are intriguing me, I am really surprised for me split
shall return an array, but wait, split might be intended from the
Chronograph module and it should return 0.

Hmmm, nil#split makes not much sense I agree, but what about
nil#to_i?
Actually that is Off-Topic, I have to admit :(.
>
> --
> CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
> Paul Graham: "Real ugliness is not harsh-looking syntax, but having to
> build programs out of the wrong concepts."
>
>
Robert

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