Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^4: Flyweights - different meaning in perl?

by adrianh (Chancellor)
on Dec 16, 2002 at 01:34 UTC ( [id://220095]=note: print w/replies, xml ) Need Help??


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

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.

Replies are listed 'Best First'.
Re: Re^4: Flyweights - different meaning in perl?
by demerphq (Chancellor) on Dec 16, 2002 at 11:15 UTC
    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....

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

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

        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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://220095]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others sharing their wisdom with the Monastery: (5)
As of 2024-03-28 22:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found