Open doy opened 11 years ago
I think the solution here is to override isa in mop::rebased::MetaBar such that it will respond correctly to ->isa('MetaBar')
The problem with just overriding isa
is that overriding a method means modifying the class of the metaclass instance (so we'd need to change mop::get_meta(mop::get_meta('Bar'))
as well as mop::get_meta('Bar')
). This is doable, but it is an extra layer of complexity.
I'm going to make a decision and say that checking ->isa
for custom metaclasses is not something that we're going to support (at least for now). If you need an identity check, you should use a role instead. If this turns out to cause actual problems in the future, we can always change it (just leave it as "undefined behavior" for now). I'll leave this open so that we remember to document it.
Given this code:
we end up with a situation where the linear isa of
Bar
's metaclass is["mop::rebased::MetaBar", "MetaFoo", "mop::class"]
. What this means is thatmop::get_meta('Bar')->isa('MetaFoo')
is true, butmop::get_meta('Bar')->isa('MetaBar')
is false. This is fixable, but it would be a bit more effort than I'd like, since we don't have multiple inheritance. The question is, do we care about this? The equivalent code using metaroles does work:Here,
mop::get_meta('Bar')->does('MetaFooRole')
andmop::get_meta('Bar')->does('MetaBarRole')
are both true. Is this sufficient, or does this need to work withisa
too?