On Wed, Sep 12, 2012 at 5:15 PM, Matt Neuburg <matt / tidbits.com> wrote:
> Just getting started experimenting with Ruby 1.9 (1.9.3) and my scripts
> are collapsing about my ears - for various reasons, of course, but one
> of them turns out be that my code relies heavily on implicit conversion
> of Pathname to String in various string contexts. It seems that Pathname
> no longer has to_str. My questions are:
>
> (1) Why? Was this regarded as a security issue? Or has it, perhaps,
> something to do with encodings? I can see the change happening here:
>
> <https://github.com/shyouhei/ruby/commit/4ded52b623ebd1b3de12db82f8b54cc
> 156c1fd28>
>
> But I don't understand the reasons for it - and especially why they
> would do this when it causes so much breakage.

I interpret "path object is not a string." to mean that a Pathname is
not generally considered equivalent to a String.  It's the same
reasoning why some classes have #to_i but not #to_int - they can be
converted to an int - but they do not represent an integer value.  A
Pathname is at best a very special form of String (i.e. one with
certain restrictions with regard to the structure).

> (2) Any good reason why I shouldn't work around this by implementing my
> own Pathname#to_str to call to_s? It's an obvious response, but then one
> thinks, there might be something about the answer to (1) which make the
> answer to (2) "Yes, just bite the bullet and find all the places where
> you do this and call to_s explicitly." But the real problem is that I
> doubt I can find them all; it's pervasive in my code.

My solution would be to use the Pathname instance methods for various
file related operations (e.g. opening of the file) instead of using
File.open(pathname).  That is much more OO and also in some cases
probably less error prone.

If you actually need a String somewhere I'd rather explicitly invoke
Pathname#to_s for exactly the reason to make it explicit that a
conversion takes place.

Kind regards

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/