Re: PATCH: A subclassable Pathname

On 3/27/06, Mathieu Bouchard <[e-mail]> wrote:
> On Tue, 28 Mar 2006, Evan Phoenix wrote:
>
> > The reciever class is the potentially the one thats been subclassed,
> > so all it's methods should attempt to convert return values into
> > instances of itself.
>
> Is there any case where you wouldn't want the return-type to be covariant
> with the receiver? Something like a #to_ordinary_pathname() would be
> obvious ;-) but there could be some subtler cases.

Not really that I can think of.

>
> E.g. when I reimplemented Array#[] and such, I argued with myself quite a
> long time about whether it should return ordinary Arrays or MyArrays, and
> then, MyArray is not even a subclass of Array. In that case I decided that
> #[] should always return Array.
>
> I think it depends on what kind of enhancements it has over the regular
> PathName. Does it need be a subclass? Can you modify Pathname instead?

I'd rather not get into a debate between subclassing and extending
existing classes. Both have their merit. For me, organization wise, I
vastly prefer to be able to nicely subclass Pathname. This allows me
to, for instance, declare a yaml domain type on the subclass so that
my subclass shows up how I'd like in a yaml dump.

All in all, I'd rather hear arguments why my patch should NOT be
accepted. It enhances the current behavior with no detriment to the
current behavior.

I don't accept "you shouldn't need to subclass" as a valid argument ever.

 - Evan

>
> > I could extend Pathname and add my methods to it, but I've actually got
> > 2 such classes and I don't particularly want them to share these
> > methods.
>
> Why? Cause I really don't see why.
>
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - t駘:+1.514.383.3801 - http://artengine.ca/matju
> | Freelance Digital Arts Engineer, Montr饌l QC Canada
>
>


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