in reply to ISA but no farther?

I realise that I'm missing the precise context of why you want to find out you have a real OP object rather than something derived from OP (directly or indirectly), but part of the purpose of deriving from some base class is to pretend to be an object of that type, while changing the behaviour. So I'm trying to think why you (normally) would want to check that something is an OP, but only an OP.

I put "normally" there just because I realise you're probably doing some deep dark magicks (based solely on the fact you're inside B), and thus probably have a good reason to do this. But since Test::MockObject probably fakes things by changing its own ISA to go through inheritance, you're probably looking for a fairly significant overhaul of some of the object infrastructure of perl to allow T::MO to fake something without anyone else faking it.

That said, it makes perfect sense to me that a binary operator ISA operator. Because it is. However, a binary operator IS NOT a unary operator. They may share some code in common, but they aren't really the same thing. It's sorta like some of the OO examples that have Rectangle as a subclass of Square - which is wrong, because a Square ISA Rectangle, but a Rectangle is not (always) a Square. From an implementation perspective, you end up with smaller objects for Square if you put them in the object hierarchy backwards, which may be why you have BINOP as a subclass of UNOP.

Replies are listed 'Best First'.
Re^2: ISA but no farther?
by diotalevi (Canon) on Jul 20, 2006 at 16:45 UTC

    Please don't mind the relationship between the types of things and their names. That reflects the underlying C structs and how OO is emulated in C.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊