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

List:       kfm-devel
Subject:    Re: Is KHTML modularizable?
From:       Peter Kelly <pmk () post ! com>
Date:       2001-11-06 9:57:55
[Download RAW message or body]

On Mon, 5 Nov 2001, Thomas Schilling wrote:

<snip>

> Do you like sarcasm? Me, too. But I think you didn't understand me right.
> This preference to use as few memory as possible comes from assembler
> programming. But this amount of polymorphism I used in my XML-Parser which I
> wrote in C++. (BTW: Using polymorphism ain't that difficult in assembler,
> but that's not why I programmed in asm.)
> 
> Here's a short code example of what I did (notation is shorted)
> ---
> class Node {  // sizeof(Node) = 4 (only vtbl ptr.)
>    virtual getNext() { return 0; }
>    virtual getChild() { return 0; }
>  };
> 
> class Attr { // sizef(Attr) = 20 (vtbl, next, prev, parent, name, value)
>    Node* next, parent, prev;
>    char* name, value;
> 
>    virtual getNext() { return next; }
>    virtual getChild() { return 0; } // can never has one!!!
> }
> // I also had no pointer to the owning document, to get it I just had to
> // walk up the doc tree until I find the element that returns the
> // nodetype DOCUMUMENT
> ---
> Ain't this memory friendly?

We're basically doing this already... in xml/dom_nodeimpl.h you'll see 
three classes, NodeImpl, NodeWParentImpl and NodeBaseImpl. Each adds 
fields like parent, siblings, etc.

And all of the HTML element classes, like HTMLButtonElementImpl add there 
own fields as appropriate which are not present for other elements.

-- 
Peter Kelly
pmk@post.com

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