RE: Class::Trait

Class::Trait is an implementation of a research concept. The documentation on CPAN refers to several papers on it. The idea is to be able to implement "incomplete" mini-classes that can be "mixed in" to regular classes all while in a single inheritance paradigm. Its kind of like multiple-inheritance, mix-ins and deffered classes all mixed together with some strict rules on their behaviors/interactions. Where it differs most is in the concept of flattening. Trait methods are not inherited but instead flattened into the class which uses them.

So, while you are correct in regards to SUPER not being enough in the presence of multiple inheritance, Traits are specifically designed (not by me, but the researchers) to be used in a single-inheritance world. In addition traits themselves have a set of restrictions such as not being able to have state, which I extended for perl to disallow DESTROY methods (since you can't have state, you have no need for DESTORY). Also traits are only allowed to call the immediate object or its SUPER class. All this is explained much better in the papers.

I actually do not believe that it is okay to break multiple inheritance, in normal OO modules. Class::Traits is not a normal OO module, matter of fact its not an OO module at all, but more a pragma in the sense that it does all its work in the compilation stages. Traits is a very specific idea, and really still a research idea too, not really something meant for serious use yet.

RE: Class::FlyweightWrapper

On Class::FlyweightWrapper, the subroutine that you return is the one that is meant to be given the private object, not the public one. Since the caller isn't supposed to have the private object, that should be useless.

Quite true, although this brings up the whole issue of privacy and access control, which is another debate unto itself. I might argue that since the real class is already hidden from the user, they have no easy way of knowing if the method i return is from the public or private version (although they could find it out if they were really curious). But if you do not want to allow direct access to your private object, then we can alter can to do this:

sub can {
    my $self = $object{shift(@_)};
    my ($method_name) = @_;
    my $method = $self->can($method_name);
    return unless $method;
    return sub { $method->(@_) };    
}
[download]

Of course this implementation is not perfect either, as it will report as ANON in the call stack. But then again, normal use will also expose the use of the private object on the call stack. If you have more specifics of the behavior you intend Class::FlyweightWrapper to implement, we can discuss it and I'm sure find a solution, but right now you have me shooting in the dark. My point really is that it is possible, given a well thought out specification regarding the behavior, one can make it work.

Furthermore the reason why you can't inherit is because the implementation (including inheritance) is supposed to be done in the private hierarchy with public hooks defined where you decide.

Ah, this was not really alluded too in the documentation. But I would argue that I should be able to inherit from your public version as well. I mean what is the use of encapsulation when in order to inherit you are forced to break it?

Clearly Class::FlyweightWrapper, while a nice chunk of code, is not completly fleshed out to all the corners. This is not to say its bad, just that you apparently have done anything with it since 8/10/01 and its still version 0.01. If you want to work on it again and take it to the next level, I would be happy to collaborate on it with you, and then we can make sure it works with both can and AUTOLOAD ;-)

I am refraining from further comment on the other 2 implementations as they too are not really at a level where real discussion of features and implementation can take place.

My guess is that we are boring the other monks with this back and forth. I recommend we drop it (unless you wanted to get the last word in, in which case go right ahead). In the end, no matter what, I will insist that every effort should be made to make can work with AUTOLOAD, and you will likely disagree. But this is okay, diversity of opinion is one of the great things about perlmonks, as well as just another aspect of TIMTOWTDI.

-stvn

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.