> > And I'm coming in late on this. Are you saying you want
> > Exporter/%EXPORT_TAGS functionality built into the language and
> > into all objects? Wouldn't that jack up the overhead?
>
> No. All I'm saying is that this sort of construct:
>
> *{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
>
> Gives you everything that inheriting a class does, apart from the
> ->isa() relationship. And potential unwanted namespace pollution.
Isn't that potential namespace pollution anyway?
You should obviously pay attention to what you're importing....
Even now, you can explicitly
use Class ();
to import nothing, right?
> I'm thinking along the lines of;
>
> use base MyActualObjectSuperClass;
> use base XML::Sablotron::DOM => [ "Core" ];
>
> So your class ->isa("MyActualObjectSuperClass"), but ->can() all of
> the Core DOM methods, which could perhaps be tested for as
> ->mimics("XML::Sablotron::DOM", "Core"), but also as
> ->isa("XML::Sablotron::DOM") for compatibility.
Ok, forgive me. I see what you're saying, but I'm lost as to why.
As I said before, I'm feeling really dense today.
> > We musn't dictate style.
>
> No, but we should emanate good style. And I consider opening two
> class' namespaces into the same stash to be very bad style.
True enough.
("emanate"? maybe "promote".)
> Whenever I've seen Multiple Inheritance used, it has been because the
> two classes inherited are not similar; and you're just doing it to
> save yourself the hassle of splitting it into a ``servant class''
(ie,
> referring to another object & forwarding methods to it). To
> re-iterate my point, an interface is a `more correct' representation
> of this relationship. So let's make the semantics of it easy so that
> people can avoid it more easily...
I don't know if I can 100% agree with your assumptions, but I do agree
with your suggestion. :) As I said before, I prefer delegation anyway.
> Brent says that `attribute slots in a Parrot object are private to
> the object', so if you really do inherit from two classes, it should
> be the case that one class cannot access the other class' attributes.
Makes sense.
> But - if the child class accesses an attribute which is defined in
> both classes, which does it get? I think that case (MI two classes
> with clashing symbols) should be a hard run-time error.
Ah. P5 does a [EMAIL PROTECTED] search, right?
But that might not be what you want, particularly if you say
@ISA = qw / X Y /;
and you want X's foo() method but Y's bar(). If both have a foo() *and*
a bar(), you couldn't disambiguate with the order of @ISA anymore. It's
probably a rare case, but it will happen. You're right -- no clean
solution comes easily to mind. All that pops up atthe moment is
hardcoding hackery, in fact, but as I said, I'm dense today, lol....
> If attributes are declared explicitly, then this enables this test.
> In Perl 5, the approach taken with MI namespace clashes is to cross
> one's fingers ;).
lol, yeah I guess so.
So how would you write code in your proposed solution to solve the
above example case?
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
