Actually I disagree with this POV. He may reference Design patterns, but I suspect he had experience with flyweight objects before the movement developed. (Why else would he discuss flyweight objects the way he did.) Of course we wont know unless he tells us...

Personally, I don't think the technique described is an instance of a flyweight pattern, since we're taking not taking the state information from the class, just rearranging its location within the class.

The whole point of using flyweights is to cut down on the number of objects you create by removing the context-dependant information from the class. The context specific state being passed to the flyweight objects as and when necessary by its client objects.

It seems to me that you are taking a little more prescriptive approach to what a flyweight object is than is perhaps justified. From what I can tell the central tennet is to reduce overhead by not duplicating data. If this means reusing literal objects then so be it. If it means reusing attribute data in a transparent way then so be it. I dont see anything in the design pattern documentation that explicitly specifies that actual objects must be reused, only their attribute data. (Note in the definition you published there is no mention of reused objects,
    Using sharing to support large numbers of fine-grained objects efficiently
and in the one I published it only says "allows for" not that it is mandated.)

Personally I think the model as described by TheDamian perfectly fits the design pattern definition. Multiple objects can share attribute information. The fact that the pattern as used in the book isnt intended to utilize these features doesnt change the fact that this model is designed to facilitate this type of activity. And once you start doing so, storing state specific information no longer makes sense. And there you have a "normal" flyweight object. Or at least thats my understanding... Further comment is welcome.

TheDamian's technique might use some of the same stratagies as flyweights, but with a different intent.

Well if I choses to use a wrench as a hammer I havent changed the fact that the item is indeed a wrench. But I agree that at least in his discussion and in his usage he isnt trying to use the feature of flywight objects that the design pattern folks seem to consider so important.

I have to admit that I dont get too hung up on the whole design pattern movement. I agree its useful, and I agree its a positive step forward, but Im not particularly interested in interpretations that says "thats not an X because the design pattern guys say that an X must have features Y and Z". Design patterns are guidlines for how to approach and resolve real life problems. They arent end all be all solutions in of themselves. And im not really interested if solutions that I come up with meet the letter of their definitions, or if they adopt and borrow bits and pieces from everywhere.

So to recap, I personally think that the flyweight pattern as described by TheDamian is the closest published Perl OO model to what the design pattern guys would also call flyweight objects. However it is also my opinion that in Perl it is unusal to need the design patterns concept of a flyweight, and if the model offers other benefits then so be it. (In other words I dont think its that important..)

Cheers,

:-)

--- demerphq
my friends call me, usually because I'm late....