Re: PATCH: A subclassable Pathname

I think that this behavior is perfectly acceptable. The return value
is the same class as the primary Pathname (ie, the left hand side
one). Unlike numerics where coerce can decide what the return value
should be, the programmer here is the one that really should decide
anyway. If they use a Pathname with an EnhancedPathname as an
argument, they should expect to get a Pathname back.

As you've said, Array has the same issue, and I think that ruby
programmers have become accustom to this kind of behavior (I know I
have).

All fix the getwd and glob, add 2 tests, and send in the new patch in
a few minutes.

 - Evan

On 3/27/06, Tanaka Akira <[e-mail]> wrote:
> In article <[e-mail]>,
>   "Evan Phoenix" <[e-mail]> writes:
>
> > Quite right on the .glob and .getwd. I guess the tests don't test hit
> > those methods, I'll add some quick tests for those. Also, why is it
> > not so simple when a Pathname is an argument?
> >
> > For instance, the code for join tests that each argument is a Pathname
> > (which will come up as true for subclasses). The it simply uses
> > self.class.new to create the return value.
>
> The class of an argument may be different from
> self.class.new.
>
> For example, if P inherits Pathname,
> Pathname.new("...") + P.new("...") returns an instance of
> Pathname.
>
> Is it useful? intuitive? ...
>
> Note that Array has a similar issue too.
>
> % ruby -ve '
> class A1 < Array; end
> class A2 < Array; end
> p((A1.new + A2.new).class)
> '
> ruby 1.9.0 (2006-03-04) [i686-linux]
> Array
> --
> Tanaka Akira
>
>


--
When I do good, I feel good;  when I do bad, I feel bad,
and that is my religion.
    -- Abraham Lincoln (1809 - 1865)