On Thu, 10 Aug 2000, David L. Nicol wrote:
> Two fields.
>
> First is type, which is 0 for a double-precision FP
>
> 1 for a string and higher than that for a defined type in the
> defined type table.
>
> Second is the number, for type 0, and a pointer to
> the beginning of the object for everything else. Objects will
> fit in contiguous memory or will take care of their own decomposition
> if they are not, through allocation of additional objects within their
> methods.
This'll cause issues both with GC and thread synchronization. (Besides,
don't skimp on fields in the base variable structure. Memory's reasonably
cheap, and shaving a few bytes off isn't worth it anyway)
> THE DEFINED TYPE TABLE:
>
> this is where the jump tables live, rather than in the objects
> themselves, so we don't have "heaviness" of C++ virtuals.
Since the vtable takes all of a single pointer in the variables, I'm not
really sure it qualifies as heavy :)
Also, doing this means both more bookkeeping and it makes it somewhat more
difficult to put together custom vtables. (Not much more, but a little)
Also, acces via pointer indirection's often faster than an array index
indirection. (And sometimes not, of course)
If you want to throw together an RFC, though, go for it.
Dan
