From: Evan Phoenix Date: 2006-03-28T10:42:47+09:00 Subject: Re: PATCH: A subclassable Pathname 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. Well, this whole thing is about the ability to subclass Pathname. For instance, I've got a class that effectively operates on paths (ala Pathname) but provides some functionality specific to the application I'm in (like the ability to load a YAML document stored under the path). 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. I could delegate to Pathname, but that means that every time I call a method on this new class (call it EnhancedPathname), I have to convert it to an EnhancedPathname because none of the methods return EnhancedPathnames. Here's an example of the desirable behavior: class EnhancedPathname < Pathname def load_yaml ... end end ep = EnhancedPathname.new("/home/evan") p2 = ep + "work" # # p2.load_yaml # [...] The ability to subclass and extend functionality is what brings people to OO languages, so we should try and make it easier to do so. - Evan On 3/27/06, Tanaka Akira wrote: > In article <92f5f81d0603271717r1ce51d30p6c28e363dc32a09b@mail.gmail.com>, > "Evan Phoenix" writes: > > > Hm, well, thats because of the shortcut behavior in Pathname#+ which > > tests that the argument is absolute. I'll fix that and see if thats > > done other places and change them to create new instances from > > self.class. > > Why you need the receiver class? > > I cannot remember the reason except "I doubt I need to > explain why thats a good thing." > > I think this is not simple enough to avoid explanation. > -- > 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)