Hello --

On Thu, 11 Jul 2002, Stepan Kasal wrote:

> On Wed, 10 Jul 2002 12:35:54 GMT, David Alan Black wrote:
>
> > I'm not sure what the disadvantage of allowing a string argument is.
>
> The disadvantage is that people will often write "error[.]log", hoping
> that this will match the string "error.log".  The reason for writing this
> is not only the habit inherited from other languages, it may be simply
> a program which used to work in a previous version of Ruby (though it
> should not, according to the docs ;-).
>
> How would you like if a review of a new version of Ruby said this:
>
> 	We experienced non-complete backward compatibility with this
> 	version, at least.  Our old programs just stopped working, though
> 	no error message appeared.  We traced this down to a
> 	(mis-)behaviour of the split() function.   [...]
> 	We recommend reviewing all your programs carefully before upgrading
> 	Ruby, especially in a production environment.

Ummm, yes: there is (self-evidently) a backward compatibility issue.
But matz has indicated that he's considering having these methods take
strings arguments (of any length), and I think it's safe to assume
that he's on top of the compatibility question :-)

> > It's not mandatory -- you can always use a regex (or even
> > Regexp.new(s) :-)  -- so allowing strings (without auto-conversion to
> > regex) doesn't take away any functionality.
>
> I think that arguments like this one lead to non-elegant non-readable
> languages.

That's a bit of a conversation-stopper... :-)  But anyway: I'm not sure
what's non-readable about string.split("blah") where "blah" is a
string.  I'd actually tend to argue that having to recognize "blah" as
a regex (despite the presence of a string constructor) is a
readability hurdle.


David

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