[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> 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.