Re: Run-time representation of classes

"Armel" <armelasselin@hotmail.com> wrote in message
news:09-02-002@comp.compilers...
>> adding versioning is not much more than this, namely it involves the
>> addition of a table of "versions" (each version context then holding the
>> various offset tables, ...). each instance then containing a version
>> number
>> along with the class pointer (applying a group of changes to an object
>> creates a new version context, and a new version number).


> It could have been built into each object in the other 'direction'
> also, I mean having each instance contain a 'versioned_class'
> pointer, and then each 'versioned_class' having its 'version+class'
> information, you would win one int per instance and one
> class_desc.version_array[version] indirection.


this is an interesting idea, especially since it could still retain
class-identity, ...


OTOH, I could just replace the class-version field with a direct pointer to
the class-version, effectively replacing (psuedo-C, actuall field names
vary):
obj->class->version[obj->ver]
with obj->class_ver


with a few other related tweaks (changing the exact approach for looking up
the correct offset table, ...), this could improve the performance of
indirect access and versioned classes in general...


(as is, things are organized according to their position in the inheritence
graph, and so looking up the exact table requires walking up the graph and
chacking the class pointer at each step, but organizing them per-class and
doing a binary or hashed lookup could be better...).


for example (as is):
class is table[0]
class->super is table[1]
class->super->super is table[2]
class->super->super->super is table[3]
...


(however, the current approach is easiest, and I had usually reasoned that
the hierarchy is presumably fairly shallow in most cases, and so a binary or
hashed lookup is not needed...).


I don't know...




would probably still leave 'obj->class' around though, as more than a few
places in the code use it, and having to be like 'obj->class_ver->class' in
all these places would not help much ('obj->class' points to the class,
which includes lots of general info about the class, and 'obj->class_ver'
would point to info about the layout of the particular class version...).




along these lines, I could potentially also change (again) how I implement
MI, as the design I use now eliminated an "issue" which I have since
discovered may have actually been useful on semantic grounds (namely, that
the same field inherited multiple times can actually have use in having a
separate identity through each inheritence path, which formerly I had
thought was a design bug in many MI mechanisms and ended up adopting an
approach which merged all the fields by their common root).


however, to effectively utilize such semantics in my case could be a
difficulty (much of the API in general assumes only a single copy of a
particular field in an instance). this would require using a modified API in
order to deal with the MI case, and still leave plenty difficult-to-resolve
semantics and implementation issues (for example, a "qualified slot" handle,
...).


so, as is, the present semantics are probably best, even if it does hinder
some possible use cases (and can't fully emulate C++-style MI semantics...).




then again, my primary emphasis is the SI use-case anyways (as is, the
current MI support is more of a hack...).

Return to the comp.compilers page.
Search the comp.compilers archives again.