Re: PATCH: A subclassable Pathname

On Mar 27, 2006, at 6:50 PM, Mathieu Bouchard wrote:

> 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.

I think this is the right question to be asking. For general purpose  
classes, both collections and utilities (read: nearly everything in  
core, most stuff in std), where usage can vary massively based on  
platform or task, I think the answer should be "no, methods should  
generally be covariant."

Covariant return types are safe, so I don't think that is the issue  
at hand. YES, ruby is currently inconsistent with this goal, but I  
don't see that as an argument against pushing towards consistency.

> 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 don't see how either of these questions are relevant to his stated  
goal. Modifying a class is a fine solution when you need a simple  
patch that will affect the behavior of a method ONCE. But it breaks  
down as a viable solution quickly. You can't modify multiple times or  
you lose polymorphism. (eg you need multiple subclasses to change  
#to_s in 2+ different ways).

>> 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.

Multiple subclasses should be a suitable reason.

-----

Assuming that Evan's newly patched Pathname doesn't violate the  
Liskov substitution principal against the original Pathname (and I  
haven't tested it for that), I don't see why this patch doesn't go in.

--
_why: zenspider's most intense moments of solice are immediately  
following the slaughter [...]
_why: that topknot's the only thing keeping a lid on the righteous anger
bricolage: yeah, that and his flagrant obsession with dvorak