Re^6: Flyweights - different meaning in perl?

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

Only TheDamian knows :-)

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.

Let's review the definition of the flyweight pattern from Object Oriented Perl:

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.

From Overview of Design Patterns

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)

From Design Patterns

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

Comment on Re^6: Flyweights - different meaning in perl?

Replies are listed 'Best First'.
Re: Re^6: Flyweights - different meaning in perl? by demerphq (Chancellor) on Dec 16, 2002 at 19:59 UTC
Ok. First off in general I agree with most of what your saying. But I think that you have slightly missed my point. I think the crux of the matter is highlighted in these two sentences 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. The point I was trying to make was with the flyweight pattern as described by TheDamian we can do both of these things. The overall design facilitates it much more than most other OO perl models i've seen. (I think you do have to read that "allows" as meaning that objects are reused - otherwise it's just a null statement) This one of the few points where I do disagree with you. I think the allows is crucial. Sharing objects in perl in the way that they mean here is not particularly convenient. However sharing attribute data is. And as I think the core objective is to reduce overhead by sharing data, the particular mechanism by which this is effected is not particularly relevent. And the flyweight pattern allows this to be done in an easier way than most other object models. Lets put it this way, if you or I sat down to implement a flyweight object system, or a shared attribute system, we would end up with an implementation that is basically the same as TheDamians. Here we talk about sharing objects with the same state. The motivation is to reduce the overhead in having a multitude of objects. No. The motivation is to reduce overhead by not duplicating data. Sharing objects is just an means to an end. I agree however that this debate has degenerated ;-) into quibbles. However for me (and I think you too) its been a fun and educational trip. --- demerphq my friends call me, usually because I'm late....	[reply]
Re^7: Flyweights - different meaning in perl? by diotalevi (Canon) on Dec 16, 2002 at 17:19 UTC
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. Actually I think it is very clear that the motivation is reducing the number of objects. I suppose data hiding might be a benefit but in general I don't respect data-hiding efforts in perl as valid activities. The idea is that instead of having one hash per object you now have a few larger structures per class but each object is only required to be a scalar. I look at that and see Flyweight being applied to the perl structures. It's reducing redundant structures and in the process requiring less memory. It appears the typical application of FlyWeight (outside of Perl circles) is agnostic on language internals and intends to apply it to data and reduce memory load that way. This inside-out approach allows for a miminalist approach where you've got a few large arrays and a lot of small scalars instead of the more "normal" perl approach which simply has a lot of hashes. The assumption is that there is a higher memory overhead on having many hashes instead of few large arrays+many scalars. Fun Fun Fun in the Fluffy Chair	[reply]
Re^8: Flyweights - different meaning in perl? by adrianh (Chancellor) on Dec 16, 2002 at 18:33 UTC
Absolutely last comment :-) Actually I think it is very clear that the motivation is reducing the number of objects. I suppose data hiding might be a benefit but in general I don't respect data-hiding efforts in perl as valid activities. The idea is that instead of having one hash per object you now have a few larger structures per class but each object is only required to be a scalar. TheDamian's method implements a particular representation of objects in perl data structures. The number of objects (be they hashes or blessed scalars) stays the same. The amount of state (be it in a per-object hash or in a class-local array) stays the same. The flyweight pattern (in the DP world) is about making decisions about what state is stored where, and choosing a set of classes and objects that reduces the total number of objects in existence. It's a design decision (that's why they're called design patterns). You're right that TheDamian's method can be a more memory efficient way of implementing objects - but it doesn't affect the design of the object hierarchy. It's an implementation choice. Abigail-II's inside-out objects also save memory, but it doesn't make them a flyweight pattern. I'll shut up now :-)	[reply]


P is for Practical
	PerlMonks