Related articles |
---|
OOP Runtime data structures witness@t-online.de (Uli Kusterer) (2003-10-13) |
Re: OOP Runtime data structures jones@cs.ua.edu (Joel Jones) (2003-10-13) |
Re: OOP Runtime data structures me@junk.address.com (Tim Owen) (2003-10-13) |
Re: OOP Runtime data structures witness@t-online.de (Uli Kusterer) (2003-10-19) |
Re: OOP Runtime data structures Markus.Elfring@web.de (2003-10-27) |
Re: OOP Runtime data structures Markus.Elfring@web.de (2003-10-27) |
Re: OOP Runtime data structures javadesigner@yahoo.com (javadesigner) (2003-10-31) |
[3 later articles] |
From: | Uli Kusterer <witness@t-online.de> |
Newsgroups: | comp.compilers |
Date: | 13 Oct 2003 00:19:26 -0400 |
Organization: | T-Online |
Keywords: | OOP, design, question |
Posted-Date: | 13 Oct 2003 00:19:26 EDT |
Hi,
I'm working on an object-oriented programming language, and I'm
unsure about the best way to implement the runtime data
structures. Any input will be appreciated!
1) I don't intend to differentiate between classes and objects. That
is, a class can be used just like any other object, and any object can
be subclassed. I also want method invocations to be messages, so any
object that responds to the same messages as another can be used in
the other's place, like in Objective C or Smalltalk.
So, I thought that I allocate one C-string for each unique message
name, and use its address as a unique, short key to identify each kind
of message. Every object starts with a pointer to a table that maps
this unique key to the corresponding function for this message on this
object, and a pointer to the superclass.
2) I also would like to allow loading code that retroactively modifies
an existing class. That's easy for methods, but can get really hairy for
data members. I guess I
a. have to use a table like the one I have for the methods for accessing
the data members as well, and add missing data members as needed. This
would be SLOW.
b. make all the offsets to fields in my data structures relative to
the end of the base class's data members, and whenever a modification
is loaded, to change any existing objects' data. Since this would
really screw up my object pointers if I'd have to reallocate all my
objects, I'd have to make each object contain a pointer to its actual
data, which increases object overhead and takes additional time
whenever the change occurs.
c. replace the symbol table entry for the class (which is an object,
after all) with a revised copy, which will be used for creating new
objects from this moment on, while old objects will still use the old
one. This would open a whole other can of worms, though, as I'd have
two objects purporting to be of the same type but behaving
differently... I'd also have to make copies of any subclasses of my
class.
Sounds like a little much effort for what I want to do. Any
suggestions on how I could do things more effectively? At least I know
why Objective C doesn't let categories add new variables to classes
now...
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
Return to the
comp.compilers page.
Search the
comp.compilers archives again.