in reply to Inside-out objects inheriting from hash-based classes

You're innovating faster than I can keep up with it. :-)

I'm glad to see this appear finally, as "foreign inheritance" is one of the other big deals of the inside-out technique. (I like that term -- I've been searching for a good term for it for the seminar that I mentioned in Seeking inside-out object implementations, so I'll have to steal it and credit you.)

Can you talk about the design choices you've made a little bit more? From a quick skim of the code, it looks like you're using some sort of facade pattern (er, adaptor pattern, whatever) in the AUTOLOAD to check method calls against the foreign object(s), rather than using a foreign object as the blessed reference directly with the @ISA array. That does allow multiple foreign objects, but at the cost of incremental indirection.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^2: Inside-out objects inheriting from hash-based classes
by jdhedden (Deacon) on Dec 07, 2005 at 19:35 UTC
    You're innovating faster than I can keep up with it. :-)
    Yes. I'm trying to make Object::InsideOut as comprehensive as possible, hoping that will induce people to try it.
    Can you talk about the design choices you've made a little bit more? From a quick skim of the code, it looks like you're using ... AUTOLOAD to check method calls against the foreign object(s), rather than using a foreign object as the blessed reference directly with the @ISA array. That does allow multiple foreign objects, but at the cost of incremental indirection.
    Yes, the foreign method dispatching is done in AUTOLOAD. That was the suggested techique from the discussions I read. This allowed me to support multiple inheritance, as well. True, there is a performance trade-off with this form of dispatching, but it does provide maximal functionality.

    The other feature this design provides is encapsulation. The foreign object is hidden from all but the inheriting class's code. This allows the class code to control access to the guts of hash-based objects.

    Remember: There's always one more bug.
[reply]

      But what happens if you need/want to make explicit calls to a super class? 

      print( $object->Borg::comment(), "\n" );

      [download]

      Updated/expanded for clarity

      Assume that you have a method of the same name in Borg as you do in Foo:

      package Borg;

sub comment { 
    return $_[0]->{default_threat};
}

      [download]

      If I want to explicitly call the Borg version of that method, I'd call it as $obj->Borg::comment(). However, that's equivalent to this:

      Borg::comment( $obj );

      [download]

      Therefore, if Borg::comment is expecting an object of type Borg and intends to muck with its internal structure directly, this will fail since the real Borg object is hidden in a closure in Foo and keyed to $obj and $obj is just the blessed reference for the inside-out object.

      Or have I missed something?

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
[d/l]
[select]
        In the case you describe, Borg::comment is overridden by Foo::comment, and, as a result of the architecture, is not directly callable using $obj->Borg::comment.

        If it was intended by Foo's author that Borg::comment should be overridden, then no one should be writing code that uses Foo and also tries to by-pass Foo's version of the comment method.

        If the overriding was accidently, then either Foo's author can rename Foo::comment, or can provide a wrapper method so that the functionality of Borg::comment is made available under a different name.

        This is an interesting technical point, but I would imagine that a situation like this would rarely occur in practice. Nonetheless, I'll add information about this to the POD. Thanks.

        Update: Actually, this applies to more than just overridden methods. You can't use any fully-qualified method calls to inherited foreign classes. But then again, you shouldn't need to.

        Remember: There's always one more bug.
[reply]

In Section Meditations