in reply to Re^3: Beyond Inside-Out
in thread Beyond Inside-Out

I would be interested to understand more about Tye's concerns and how valid they are.

The focus of Tye's concerns is the fact that the ego() function uses its caller to decide which alter ego to produce. Here, "caller" means the package that was in force when the call to ego() was compiled. Now, it is possible to do things like 

package Foo;
sub Bar::method { my $ego = ego($_[0]); ... }

[download]
That would indeed produce an anomaly: A method in class Bar that accesses the ego belonging to Foo. On the other hand, that would be the described behavior, for better or worse. It isn't something that easily happens by accident while you're writing your accessors. It may even be useful in some situations, I haven't thought about it much. In general, the Alter-approach assumes that methods are compiled in the class their name resides in.

Tye has another objection which I'm not sure I understand. If I understand it right it is about qualified method calls, in the form 

$obj->Class::method(...);

[download]
but I think an Alter-based class would behave exactly as it should with these.

Anno

Replies are listed 'Best First'.
Re^5: Beyond Inside-Out
by xdg (Monsignor) on May 30, 2007 at 13:14 UTC
    In general, the Alter-approach assumes that methods are compiled in the class their name resides in.

    That assumption breaks badly for classes that "mix-in" methods from other modules. Plug-ins (e.g. many of the web frameworks) would be a good example of this kind of thing, where a class imports one or more methods from the plug-in.

    -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]
      Methods imported as plug-ins would have to go through a well-defined interface, like a set of pre-appointed methods, to work with any class. That would continue to work with Alter-based classes. By name and purpose, a "plug-in" can't make assumptions about the makeup of the objects it will work with. I don't see a problem.

      The remark you quoted, "...the Alter-approach assumes that methods are compiled in the class their name resides in" concerns only code that accesses the object data directly. An imported method won't do that.

      Anno

[reply]
        By name and purpose, a "plug-in" can't make assumptions about the makeup of the objects it will work with.

        See, for example, CGI::Application and how its plugins work. It's just Exporter bringing in things as requested.

        There's no reason that plugins couldn't be written to work with Alter in some way, but many existing plugins violate the assumption you stated.

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

In Section Meditations