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...

Also, in case this isn't obvious, none of my comments are intended to be a criticism of the method presented in Object Oriented Perl. It's a fine and useful technique. I've used it myself. The only thing I'm querying is it being an instance of a flyweight pattern.

It seems to me that you are taking a little more prescriptive approach to what a flyweight object is than is perhaps justified.

Possibly. But the use of the term flyweight in Object Oriented Perl is the only one I have ever come across that isn't to do with removing context-dependent information to allow you to perform your task with fewer objects.

From what I can tell the central tennet is to reduce overhead by not duplicating data.

A less well-known approach to encapsulation uses scalar-based objects to implement a technique known as the flyweight pattern. In the flyweight pattern, objects donít carry around their own information, so that information canít be accessed directly via the object. Instead, flyweight objects merely serve as an index into a shared table of values, stored within the class itself. For example, an object may be an integer that indexes into a table of values stored as a class attribute.

So:

The number of objects stays the same

The state stored by each object stays within it's class

The state stored by each object remains the same. It's just stored in the class, rather than within the object.

The method is used to implement data-hiding

Note we are not removing any duplicate state. We are moving state from the object to that objects class.

The motivation for doing it is data-hiding, not reducing duplicate state.

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.

(I think you do have to read that "allows" as meaning that objects are reused - otherwise it's just a null statement)

Using sharing to support large numbers of fine-grained objects efficiently

Some applications could benefit from using objects throughout their design, but a naive implementation would be prohibitively expensive ...
A flyweight is a shared object that can be used in multiple contexts simultaneously
...
Intrinsic state is stored in the flyweight; it consists of information that's independent of the flyweight's context, thereby making it sharable. Extrinsic state depends on and varies with the flyweight's context and therefore cannot be shared. Client objects are responsible for passing extrinsic state to the flyweight when it needs it.

Here we talk about sharing objects with the same state. The motivation is to reduce the overhead in having a multitude of objects.

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.

To me it is clear that the Object Oriented Perl Flyweight and the Design Pattern Flyweight are completely different beasts. Sorry :-)

They both describe useful things - but they're different.

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..)

It no more or less unusal in perl to use flyweights (in the DP sense) than it is in any other language. It depends on what you're developing. It's not a language issue, it's a design issue.

To some extent it's pointless to argue about these definitions now. The particular implementation in TheDamian's book has become the accepted definition of a flyweight pattern in the perl world. I now understand what that definition is - and that's fine.

However, you will find flyweight pattern means something quite different to a big chunk of the rest of the world.

While calling a wrench a hammer doesn't stop it being a wrench, it can make working with others in a machine shop harder than it could be ;-)

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other