Personally, I think that going for this kind of hard encapsulation is self-defeating. The whole point of OOP is to decouple your code. If your colleague is violating this decoupling, then it is incumbent upon you to educate your colleague. Education is better done non-coercively. If your colleague refuses to learn, quit. Life is too short and, despite the general slowdown, the jobs are out there.
in reply to Encapsulation through stringification - a variation on flyweight objects
If you're providing a module for general consumption, you don't have to do B&D development. This is not consistent with the culture of the entire LAMP model. If someone abuses your appropriately-documented interface, that's their problem, not yours. It's your job to make your stuff mistake-proof, not fool-proof. Fools are infinitely more cunning than any of us can ever be.
Now, this form of implementing flyweight objects is flyweight only in the creation and memory usage (and if you're using stringification of hashrefs as your index, you don't even have that benefit).
We are the carpenters and bricklayers of the Information Age.
Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.