I've studiously avoided the term "flyweight objects" as I have only ever seen it here and didn't really understand its meaning. I'll stick to "Inside-out" which only has meaning in perl terms as far as I am aware.

Fair enough, but other people have - which makes me suspect it means something different in the perl and design pattern worlds.

Which would be annoying. One of the main advantages of the design pattern movement for me is the development of a common vocabularly (finally, everybody knows what a singleton is :-). If it means something different in the perl world it would be useful to know.

Well following this thread, and diotalevis comment I did a little research into the flyweight pattern. And it would seem that there are two different ideas being discussed. Its possible (and I think likely) that the concepts were originally the same, but I suspect the design pattern movement redefined and extended the concept from its earlier use. But i have little evidence to back up this hunch. Heres a quote from a design pattern site about the design pattern schools concept of a flyweight pattern

If instances of a class that contain the same information can be used interchangeably, the Flyweight pattern allows a program to avoid the expense of multiple instances that contain the same information by sharing one instance.
Overview of Design Patterns

however this concept seems to be different from that briefly mentioned elsewhere and more importantly discussed in TheDamians book Object Oriented Perl. I think the later is the source of many peoples concept of the flyweight pattern in Perl, and probably derives from the earlier usage of the term "flyweght".

Flyweight objects are most frequently used in OO languages that pass objects around by value because flyweight objects objects remain extremely small (no matter how much data they contain). Hence they are cheap to pass around. Because Perl Objects are invariably accessed via references, this advantage is not signifigant.

However, the flyweight pattern still has something to offer in Perl, because it provides a simple mechanism for preventing direct access to abject attributes, thereby enforcing encapsulation. As a bonus, it also provides a means of easily keeping track of every object in a class, something closure-based encapsulation doesnt provide.

Damian Conway -- Section 11.3 Object Oriented Perl (Manning)

He then goes on to frame an object model that he calls the Flyweight Pattern. The idea of this is simple. Instead of storing attribute data in the object directly an object only holds a key into a lexically held hash that holds all of the objects for the class. The accessors extract this key from the object and then use it to look up the real object from the privately held table. In his example he uses soldiers and their ids, with a reference to the ID being blessed. (He points out that this has the weakness that it provides a means to violate encapsulation as an object can magicaly "transform" itself into using a different set of attributes. He discusses various approaches to making this less likely or impossible.)

Now the pattern he describes is still compliant with the both usgaes of "flyweight". Two distinct objects can share attributes, furthermore the actually item that represents the object is "small" from an outside POV, even if the fact that its blessed is ignored.

So I think this is a stuation that is similar to the term "closure" in perl. Generally speaking closures in Perlspeak are the same thing as closures in CSspeak. However all too often you see the term used as a synonym for "anonymous subroutine". In fact I would say that most non CS types would volunteer this is a defintion for a closure (assuming they knew what one was at all.) And just as much as this usage is a distortion and oversimplification of the real concept of "closure", I think that the term flywieght pattern has come to reflect primarily the idea of indexing a class specific lexically held register of objects, and not so much the idea of sharing attribute data between those objects. So from that point of view I would say its obvious that InsideOut objects fits that pattern. But....

And this is where I take the other point of view, and try to answer diotalevis question

I don't have my copy of _Design_Patterns_ handy but isn't this just a Flyweight implementation?

At first glance the flyweight object design as described by TheDamian is very similar to Abigail-IIs inside out objects. The fact that inside out objects use a seperate hash for each attribute is a minor twist that doesnt distract much from the flyweight pattern. However the use of the references ID or some other reference/object specific unique identifier as the key into the attribute table(s) does in my opinion mean that it is not a flyweight implementation. Two distinct objects have in principle completely unique attribute representation, the objects do not by design share attributes. (Excepting that they can reference shared data if they so choose, but this is true of all object representations in Perl).

Furthermore, Abigail-IIs pattern means that we can wrap an arbitrary number of InsideOut subclasses around any class/object. InsideOut objects fundamentally don't care about what item their blessed reference points at. However the flyweight pattern the data is small for sure, but it is very relevent to the objects internal state. You couldn't just wrap the Soldier class in TheDamians book around an IO::File object for instance. You could however do so with his BaseballPlayer example.

So to sum up, the flyweight pattern in perl seems to focus on aspects that design pattern enthusiasts will see as inconsequential, but it still shares the same underlying ideas. InisdeOut objects are in my opinion not flyweight objects from the design pattern point of view, but have similar enough perl implementations that they are easily mistaken as being the same.

Updated: Minor typographical errors have been corrected.

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