[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