I must admit i hadn't thought of a solution to that problem successfully before, although i've had this problem whenever i really wanted to subclass a module i didn't write. It wasn't possible, because whatever new attribute i introduced, i could not be sure it wouldn't break something with the next version of the Superclass...
Abigail-II's solution does not only seem to solve that, it does solve the problem. As pointed out in posts in the above mentioned discussion, this technique makes it neccessary to use accessor/mutator methods, which is what we want when we use OO.
So I've come to the conclusion that these "Inside Out" objects (as Abigail calls them) are the better approach when you want subclassable OO. There's no need to rewrite classes that use the popular way, most classes aren't subclassed anyway, but if you wanted to subclass GD::Image you'd have a problem: how to call your member variables?
The next step
There are some weaknesses that might seriously stop you from thinking the solution is useful. But wait: They're there because it's not the popular way.
My contribution is an RFC: A superclass for all classes using that new methodology to solve at least four of these problems: the DESTROY method, the lexically limited data-variables, the serialization issue and finally the methodmaker. Probably the stringification problem can be solved generally in that class.
I have already posted an idea in the disucussion, but this already has developed and here comes the result:
This is the first question: the name, how should that superclass be called? 'OO' is just a thought and probably no too good idea.
This is not a question, but the idea: Store all the information right here in that lexical. A question is the structure: Class,Field,Object, which would more directly inherit Abigail's idea or Object,Class,Field, which has the advantage that the destruction can be done easily without tricks or search.
Should there be something like this constructor at all? You see, it is quite unneccessary, but what else should a constructor do and why should every class write something similar?
These two are the crucial point of the whole thing: They get/store attribute data depending on the caller. What? Yes. These two are not to be used anywhere except in the package that defines a class. This way each class has it's own data slot as the idea is.
The names of these two must be carefully chosen, but probably 'oo_' can be avoided by classes easily.
Jep, that's all about the possible memory leaks. Object deletion causes object data deletion. by having this in the superclass, you needn't rewrite it in every class.
This is clear and is subject to be made more advanced but shows that it's easy to create accessor/mutator methods ala MethodMaker.
Now one can write a serialization/deserialization method in that class. The stringification thing can be helped out using overload::StrVal as proposed by adrianh.
I hope this RFC is an inspiration to some as Abigail's post was inspiration to me.