Alternative object model

[Harri Porten]

On Mon, 17 Feb 2003, Maciej Stachowiak wrote:

> > When it comes to Apple's optimized storage of Numbers I would still
> > like to present the approach taken in QSA first. It allows for
> > more types to be stored more efficiently without coding any
> > special excemptions.

[a lot of explanation and pro&con analysis skipped. Maciej probably won't 
find much new thoughts below.]

> Can you give me access to the union-based code so I can make some more 
> informed remarks?

You can find the latest version at ftp://ftp.trolltech.com/qsa/ . Note
that this implementation is under the GPL and IP of my employer. But I can
give you a rough overview of this very part of my long term plans stemming
back to the KDE 2 days. Other's can be found in kjs/DESIGN.ideas.

I had always been toying with the idea of splitting up data from the type.
Only later I learnt that Tcl (and probably also Python) have a similar
architecture (it's C counter part, of course). What I invisioned is to
have a single object class

 class Object {
    Type *type;
    union {
       double d;
       int i;
       bool b;
       Imp *imp;
       ...
    } data;
    ...
 };

which is *the* handle for simple values and more complex objects. All the
type specific implementations would go into a seperate class* like

 class Type {
   virtual bool toBoolean( const Object *thisObj ) const;
   virtual double toNumber( const Object *thisObj ) const;
   virtual Object construct( const List &args ) const;
 };

All simple types (Null, Undefined, Boolean, Number, Date and String(!))
would store their data in the union (if at all). Only more complex types
would allocate an extra Imp object. For convenience reasons the Object
class would have functions like

UString Object::toString() const
{
   return type->toString( this );
}

One of the design goals (apart from saving new calls) was to have a single
kind of object (fixed size, non-virtual) that could easily be stacked and
copied around for efficient use. In a stack machine for example.
The other goal was to have type descriptions without creating instances of
this type. That's useful when one wants to introspect objects at
development or "compile" time.

Now, I have to admit that I was rather eying at ECMAScript 4 which
contains a Type system, operator overloading (now deferred) etc. And
although I tried to establish Value and Object as *the* main kjs object
handles (by making their ctors taking an Imp* explicit for example) the
trend has been going in a different direction. I can't even rule out that
this extra level of indirection will always be less efficient). All I know
that the QSA interpreter is much faster than kjs in KDE 2 but that's also
because of other optimizations. Those were in part so extremely source
incompatible that I never merged them.

Harri.

* You may have noticed the seeming lack of an ExecState equivalent. It's
there but it's hidden somewhere else ;) Not completely suited to our
current khtmlpart implementation, though.