Re^4: Doubt about fly-weight objects.

I still don't get it. Let me make sure I understand what you are saying (please correct me where/if I got something screwed up): You're saying that you've got, let's say: a million instances of class Letter. The instance data of such a class is basically: a single character.

Now, if you used non-fly-weight objects, you'd have each instance of the class be a reference to a scalar containing a character. So that's one million times a reference + one million times a character. Or, basically, one million times a platform-dependent, but small, number of bytes.

Let's compare to fly-weights. With fly-weight-objects, you'd have one million times a reference to nothing (probably)... that is a scalar reference pointing to undef, I'd guess. Plus you'd have a hash mapping one million stringifications of a scalar reference to a character... so that hash contains one million characters, plus one million hash keys. That totals to one million times (a scalar reference + a character + a stringified scalar reference). That's considerably more than if you didn't use fly-weight objects (because a 20-odd character long string is pretty big compared to a scalar reference and a single character).

If you'd chosen some sort of instance data that were actually larger (as opposed to a single character, which is about as small as you can get), then the difference between one reference and a reference plus a hash-key (stringification of that reference) would actually be inconsequential. Your example, though, actually makes fly-weights take up way more than twice as much space (I think).

So, that's how I interpretted the situation you were laying out. I assume I just misintrpretted it... but how exactly did I?

------------
:Wq
Not an editor command: Wq
[download]

Comment on Re^4: Doubt about fly-weight objects. Download Code

Replies are listed 'Best First'.
Re^5: Doubt about fly-weight objects. by adrianh (Chancellor) on May 19, 2005 at 08:13 UTC
Your example, though, actually makes fly-weights take up way more than twice as much space (I think). You're right. So, that's how I interpretted the situation you were laying out. I assume I just misintrpretted it... but how exactly did I? The GoF example was dealing with a WYSIWYG word processor, so "character" was more complicated than a single byte. For example: A naive implementation of a bitmapped character in a word processor might (in Perl) look something like this: `my $char = bless { char => 'e', face => 'Times', size => '12pt', bitmap => '... some binary data ...', row => 12, column => 22, }, 'BitmapCharacter'; ... $char->render # draw a 12pt Times letter 'e' at row 12, column 22` [download] So if we have a a bit of text that says "errol eats enough eggs everyday" then we have 6 x 'e' BitmapCharacter objects that only differ by their row and column attributes. In the GoF language we say that the row and column attributes are extrinsic state - they're dependent on the characters context (as opposed to intrinsic state which is context independent). The GoF Flyweight pattern is to rip out the extrinsic state from the object so we'd have something like: `my $char = bless { char => 'e', face => 'Times', size => '12pt', bitmap => '... some binary data ...', }, 'BitmapCharacter'; ... $char->render( 12, 22 ) # draw a 12pt Times letter 'e' at row 12, colu +mn 22` [download] So the container now has to pass the extrinsic state and we can use the same object for each occurance of each letter - saving lots of space.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Doubt about fly-weight objects.
by adrianh (Chancellor) on May 19, 2005 at 08:13 UTC

Your example, though, actually makes fly-weights take up way more than twice as much space (I think).

You're right.

So, that's how I interpretted the situation you were laying out. I assume I just misintrpretted it... but how exactly did I?

The GoF example was dealing with a WYSIWYG word processor, so "character" was more complicated than a single byte.

For example: A naive implementation of a bitmapped character in a word processor might (in Perl) look something like this:

my $char = bless {
    char => 'e',
    face => 'Times',
    size => '12pt',
    bitmap => '... some binary data ...',
    row => 12,
    column => 22,
}, 'BitmapCharacter';

...
$char->render # draw a 12pt Times letter 'e' at row 12, column 22
[download]

So if we have a a bit of text that says "errol eats enough eggs everyday" then we have 6 x 'e' BitmapCharacter objects that only differ by their row and column attributes.

In the GoF language we say that the row and column attributes are extrinsic state - they're dependent on the characters context (as opposed to intrinsic state which is context independent).

The GoF Flyweight pattern is to rip out the extrinsic state from the object so we'd have something like:

my $char = bless {
    char => 'e',
    face => 'Times',
    size => '12pt',
    bitmap => '... some binary data ...',
}, 'BitmapCharacter';

...
$char->render( 12, 22 ) # draw a 12pt Times letter 'e' at row 12, colu
+mn 22
[download]

So the container now has to pass the extrinsic state and we can use the same object for each occurance of each letter - saving lots of space.

[reply]
[d/l]
[select]