[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: primitives
> Are primitives like _RemoveSlots: and _AddSlots: going to be useable
> within methods in the next release?? This would be cool, because it
> would help with data inheritance.
>
No (see the release message). They do work in our current system
(i.e. you can change objects while the program is running), but we
want thing to stabilize a bit before putting them into a release.
> If you use the model for inheriting data which adds an assignable
> dataParent slot to objects which inherit data, it slows down message
> sending.. If we could use just add the slots from data parents
> directly, it would speed things up a lot...
No! This would actually slow down the system a lot. The reason is
that programming primitives change things which normal Self programs
cannot change, such as the format of objects or the value of constant
slots. As a result, all compiled code which depended on the old value
of a constant slot (or the old format of an object) must be flushed
and later recompiled.
There is no free lunch... Self programs can be made fast by
constant-folding many lookups, but if you frequently change the
underlying "constants" you lose.
What you really want is "write-once" slots which you could initialize
at cloning time. In this way, you could express the fact that a
parent slot isn't really assignable, i.e. does not change once an
object has been created. This would be a good documentation aid
(helping others to understand your programs) while at the same time
providing a hint to the compiler.
-Urs