From: Ryan Davis Date: 2006-03-28T19:04:37+09:00 Subject: 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