in reply to Re^2: displaying package variable from inherited method.
in thread displaying package variable from inherited method.

By the way there must be a name for what I'm trying to do, is it "object introspection"?

More like "breaking encapsulation".

The whole point of classes and objects is polymorphism. That is, given an object, you don't care what its specific type is as long as it supports the operations you want to perform on it in a meaningful way.

In your specific case, there's a perfectly good way to get that instance data without relying on package variables or symbolic references or even caring about the specific type of the class. That way is calling a method.

With only a couple of classes, it might look like you're duplicating data by overriding methods. Maybe so... but it takes little imagination to see an expanded system with more subclasses, some of which can reuse their parent data (and good luck coding around that by accessing package variables symbolically!) and others that can override the parent method to call it and add, delete, or modify just one particular field in the results.

You're making a lot more work for yourself trying to work against the object system. Embrace it!

  • Comment on Re^3: displaying package variable from inherited method.

Replies are listed 'Best First'.
Re^4: displaying package variable from inherited method.
by wazoox (Prior) on Jun 10, 2006 at 20:26 UTC
    But in that particular case, my objects represent data files that work exactly the same way (same methods all along) but carry different data. There isn't any method in any of the "children" classes : each children class really represent a "polymorph version" of the parent class, which contains all meaningful behaviours. And actually there isn't anything in my code that rely on this or that class : except of course when reading or writing the target file, I have to read it the right way, or feed it with the right data. The data is polymorphic, not the behaviour.
    Would I avoid that call from the parent to the child to call data, I'd need to duplicate most method exactly (there aren't any differences!) in all the classes. Wouldn't it be stupid and unmaintanable?
    I really don't think it can be called "breaking encapsulation", because nothing in the parent classes rely on what is inside the child class.
    Please shed some light on me if you feel differently...
[reply]
      The data is polymorphic, not the behaviour.

      Same thing.

      Look at how much work you're doing your way. Look at how little magic you need to do it my way.

      Encapsulation, object-wise, is hiding data behind polymorphic behavior. I don't know how to say it any more plainly than this. Mixing raw data access and polymorphism usually bites me, and I think the fragility of your solution here is evidence that it's already biting you.

[reply]
        I understand your point now, thank you!
[reply]

In Section Seekers of Perl Wisdom