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"                        # #<EnhancedPathname:/home/evan/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 <[e-mail]> wrote:
> In article <[e-mail]>,
>   "Evan Phoenix" <[e-mail]> 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)