I have some issues with the way attributes are referenced. According to the
PDD:
> classoffset Ix, Py, Sz
>
> Returns the offset of the first attribute for class Sz in object Py.
>
> getattribute Px, Py, Iz
>
> Returns attribute Iz of object Py and puts it in Px. Note that the
> attribute number is an absolute offset.
So, compilers are expected to know the relative offsets of attributes within
each class? That's reasonable enough, assuming that attributes are only
directly accessed by code whose objects' classes have been declared.
> addattribute Px, Sy
>
> Add attribute Sy to class Px. This will add the attribute slot to all
> objects of class Px and children of class Px, with a default value of
> Null.
Should we just try to ensure that any class which wants to add attributes
to itself always uses the named version of getattribute? Do we allow code
which modifies other classes' attribute lists? Do we need to mark classes
as numeric/named attribute access, and restrict addattribute's use to
classes which use named attributes?
As well as involving much finding of instances, and moving of their attribute
values, this isn't thread safe (please excuse my lack of PASM syntax
knowledge):
classoffset Ioff, Pobj, Sclass
# Some other thread calls addattribute on Pobj's class
getattribute Pattr,Pobj,Ioff
# Now we have the value of the wrong attribute in Pattr
--
Peter Haworth [EMAIL PROTECTED]
"There is no reason to use multithreading except if you are a marketing guy
at Sun or Microsoft and your analysis says that it is cheaper to ram
multithreading down people's throats than to fix the insanely huge process
creation latency of your broken poor excuse of an operating system."
-- Felix Leitner
