[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: KSpread cells
From:       Werner Trobin <wtrobin () mandrakesoft ! com>
Date:       2000-05-22 11:31:25
[Download RAW message or body]

David Faure wrote:
> 
> I wondered about that too, yesterday. Let's see. KSpreadCell has
> 
> 16 ints
> 1 double
> 9 bool
> 4 QString
> 1 pointer to cell
> one QList (dependencies)
> one Style
> one Content
> pointers to QSimpleRichText, KFormula, KSParseNode
> cellprivate

Well... and cellprivate seems to inherit QObject (36 bytes, at least)...

> 3 pointers to KSpreadConditional
> 
> This is quite a lot indeed. This cries for inheritance, if you want my opinion.
> Well, if a cell can only be rich text, _or_ a formula, _or_ a basic cell.
> If it can be several at once, inheritance doesn't help.
> 
> Or perhaps more contained objects -> for instance for the 'obscuring cells'
> and 'extra cells' stuff, which takes quite a lot ints in the count above,
> even if not used.
> 
> On the bright side and to answer your question, yes, cells are only
> created where there is something. You don't have 65536 cells created
> for an empty document or something like that ;-)

Yep - this would have been a "killer feature", indeed :)

> What's the flyweight pattern ?

Ok. I've read a nice book (Design Patterns, by Gamma, Helm, Johnson,
and Vlissides) and they describe a pattern which is called "flyweight."
Maybe this helps here - don't know exactly, because I'm not very
familiar with KSpread's internals.

I'll try to describe it in a few words (via an example mentioned in the
book) - ask if I left out something important :)

They assume that someone wants to write a KWord-like-app and that the
programmer says that he doesn't want to have "Paragraph" objects building
the whole document (i.e. a paragraph is the "atom"), but he wants every
glyph(!) to be an object. Now imagine that every glyph would store all
the formatting info :)
They decide that it would be good to get all the "common" information
out of the object (formatting,...) and store only the bare minimum which
is needed (i.e. character code). All the formatting stuff is stored in a
separate list.

This list is initialized to hold one "character-table" object with the
standard formatting options (i.e. font, font size, color,...).
This object holds a complete character set and all the formatting stuff
for it.

Every glyph object holds only it's character code and whenever the user
changes the formatting a new character table object is added to the list
(if it's not there already).

To create a relationship between the glyphs and the char tables they
create a tree structure. There are two possible node types for that
tree: The first one just holds a count (i.e. the area it's "responsible"
for) and a list of subnodes and the other one holds a count and a pointer
to the correct char table (i.e. <count> characters of this char set are
represented by this node).

When outputting a line, the "client object" (i.e. the Paragraph, Page,
the Row, or whatever object containing the glyphs) traverses the tree.
This means that it traverses down till is reaches a "leaf" and then
gets its pointer to the character table. This pointer is passed to
all the glyphs (organized in a list) till <count> is reached. Then is
seeks the next leaf and goes on.

The glyphs use the pointer to get hold of the correctly formatted
character (via the char code :) and print/draw it...

The key concept here is the distinction between intrinsic and extrinsic
state. 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 can't be shared. Client object's (the ones using the "tiny"
object's) are responsible for passing extrinsic state to the flyweight
when it needs it.


I really hope that this was clear, but I don't think so :o)

> David, who realises he really needs to get a full time KDE job ;-)

/me cheering: David! David! David!...

-- 
Werner Trobin - wtrobin@mandrakesoft.com

[prev in list] [next in list] [prev in thread] [next in thread]