http://qs321.pair.com?node_id=220046


in reply to Re^2: Flyweights - different meaning in perl?
in thread Yet Another Perl Object Model (Inside Out Objects)

    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

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

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

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

  • Comment on Re: Re: Re: Flyweights - different meaning in perl?

Replies are listed 'Best First'.
Re^4: Flyweights - different meaning in perl?
by adrianh (Chancellor) on Dec 16, 2002 at 01:34 UTC
    Well following this thread, and diotalevis comment I did a little research into the flyweight pattern.

    Thanks for the info! It's been so long since I read TheDamian's book I'd completely forgotten this. (You've also made me realise that somebody has nicked my copy since it's not on my bookshelf... grrr... darn sneaky coworkers...).

    Fortunately the relevant chapter is online.

    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.

    It looks like it was the other way around. TheDamian references Design Patterns in his book.

    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.

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

[reply]
      It looks like it was the other way around.

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

[reply]
        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 ;-)

[reply]

In Section Meditations