Comments on: The ActionScript 3.0 Flyweight Saga: Part III Aggregation Aggravation, Stuff on the Stage and the Intrinsic State http://www.as3dp.com/2007/09/18/the-actionscript-30-flyweight-saga-part-iii-aggregation-aggravation-stuff-on-the-stage-and-the-intrinsic-state/ OOP for Flash, Flex and AIR Mon, 08 Sep 2008 14:35:17 +0000 http://wordpress.org/?v=2.6.1 By: Bill Sanders http://www.as3dp.com/2007/09/18/the-actionscript-30-flyweight-saga-part-iii-aggregation-aggravation-stuff-on-the-stage-and-the-intrinsic-state/#comment-231 Bill Sanders Wed, 17 Oct 2007 21:52:31 +0000 http://www.as3dp.com/2007/09/18/the-actionscript-30-flyweight-saga-part-iii-aggregation-aggravation-stuff-on-the-stage-and-the-intrinsic-state/#comment-231 Hello Thomas and Andres, The whole issue of intrinsic and extrinsic states is at the heart of the Flyweight. I've re-done everything and put it into a 20pp paper that I'm taking to OOPSLA in Montreal, and I'll probably put it here once I get their feedback. However, let me see if I can address your queries, One of the reasons that the Flyweight is so efficient is that it separates the intrinsic from the extrinsic and further from what you'd call the external. That means that a single object (a graphic in this case) can be re-used (a shared object) as a single instance. The extrinsic states amount to the variation that you allow beyond the intrinsic state. In this case, I used the x and y position along with some parameters for the shape of the object. Once beyound the extrinsic states, some interesting things begin to happen. For example, rotation is what might be called an "external" state. If I rotate any single reference to the object as far as rotation is concerned, the entire block will rotate. The same is true with any other state that was not built in as an extrinsic state. So if rotation is important for individual items (airplanes) I would simply add rotation as an extrinsic state. Also, this blog was written more to get developers (like yourself) involved in a discussion of the Flyweight. If you look around at examples, several get it wrong and others really do not use it as it is intended--bacically to take a single intrinsic state and vary it with extrinsic states in side a single instance to save space and increase the execution of a program. The original example in GoF is far better than the one I used because there are so many more references -- a word processor re-using the glyph set. The intrinsic value is the character (a,b,c,d, etc.) and the extrinsic is the row and column on the page. In a thousand page book (The Java Bible)the letter "e" may be used 100,000 times. However, with a flyweight, it is rendered once and re-used as a shared object 100,000 times. Multiply that with all of the characters used over 1,000 pages and you can see why the Flyweight is so valuable. Hello Thomas and Andres,

The whole issue of intrinsic and extrinsic states is at the heart of the Flyweight. I’ve re-done everything and put it into a 20pp paper that I’m taking to OOPSLA in Montreal, and I’ll probably put it here once I get their feedback. However, let me see if I can address your queries,

One of the reasons that the Flyweight is so efficient is that it separates the intrinsic from the extrinsic and further from what you’d call the external. That means that a single object (a graphic in this case) can be re-used (a shared object) as a single instance. The extrinsic states amount to the variation that you allow beyond the intrinsic state. In this case, I used the x and y position along with some parameters for the shape of the object. Once beyound the extrinsic states, some interesting things begin to happen. For example, rotation is what might be called an “external” state. If I rotate any single reference to the object as far as rotation is concerned, the entire block will rotate. The same is true with any other state that was not built in as an extrinsic state. So if rotation is important for individual items (airplanes) I would simply add rotation as an extrinsic state.

Also, this blog was written more to get developers (like yourself) involved in a discussion of the Flyweight. If you look around at examples, several get it wrong and others really do not use it as it is intended–bacically to take a single intrinsic state and vary it with extrinsic states in side a single instance to save space and increase the execution of a program. The original example in GoF is far better than the one I used because there are so many more references — a word processor re-using the glyph set. The intrinsic value is the character (a,b,c,d, etc.) and the extrinsic is the row and column on the page. In a thousand page book (The Java Bible)the letter “e” may be used 100,000 times. However, with a flyweight, it is rendered once and re-used as a shared object 100,000 times. Multiply that with all of the characters used over 1,000 pages and you can see why the Flyweight is so valuable.

]]> By: Thomas F http://www.as3dp.com/2007/09/18/the-actionscript-30-flyweight-saga-part-iii-aggregation-aggravation-stuff-on-the-stage-and-the-intrinsic-state/#comment-229 Thomas F Wed, 17 Oct 2007 16:52:32 +0000 http://www.as3dp.com/2007/09/18/the-actionscript-30-flyweight-saga-part-iii-aggregation-aggravation-stuff-on-the-stage-and-the-intrinsic-state/#comment-229 I can't see the point, too. I can’t see the point, too.

]]> By: Andres A. http://www.as3dp.com/2007/09/18/the-actionscript-30-flyweight-saga-part-iii-aggregation-aggravation-stuff-on-the-stage-and-the-intrinsic-state/#comment-218 Andres A. Sat, 29 Sep 2007 22:40:38 +0000 http://www.as3dp.com/2007/09/18/the-actionscript-30-flyweight-saga-part-iii-aggregation-aggravation-stuff-on-the-stage-and-the-intrinsic-state/#comment-218 As I was going over the code I realized that 'cir1' and 'cir2' hold references to the exact same object, which is obviously not an accident since that is the whole point of the Flyweight pattern, to reuse objects as much as possible. But then I asked myself how would you modify the extrinsic state of each button without affecting the other. For example, if you set the x and y position of cir2, you are essentially setting the x and y position of cir1 as well since both refer to the same Sprite object. Also, if you remove cir1 from the display, you'll remove cir2. cir1.x = 200; //cir2.x will also increase by 200 removeChild(cir2) //will also remove cir1's circle graphic since both //cir1's and cir2's graphics are located in the same //Sprite object. So how do you remove, say cir2, //without removing cir1's graphic? As I was going over the code I realized that ‘cir1′ and ‘cir2′ hold references to the exact same object, which is obviously not an accident since that is the whole point of the Flyweight pattern, to reuse objects as much as possible. But then I asked myself how would you modify the extrinsic state of each button without affecting the other. For example, if you set the x and y position of cir2, you are essentially setting the x and y position of cir1 as well since both refer to the same Sprite object. Also, if you remove cir1 from the display, you’ll remove cir2.

cir1.x = 200; //cir2.x will also increase by 200

removeChild(cir2) //will also remove cir1’s circle graphic since both
//cir1’s and cir2’s graphics are located in the same
//Sprite object. So how do you remove, say cir2,
//without removing cir1’s graphic?

]]>