[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

shower strikes again (whap!)

a couple problems with this:

1) stubs don't have identity.  Several stubs might virtually point to
the same object.  I can imagine making them canonical, but it could be
expensive:  I expect at least 3 times as many stubs as shepherds.

2)I don't think objects can be changed in place in a portable fashion.
MarkM?  Hill?

We should definitely keep this in mind though.  It does simplify some
things.  It might actually be easier than forwarding messages if
objects can be recreated in place.  Your assumptions were correct,
all shepherds are small (4 pointers max?), and even the things that
mutate stay within a pointer of their original size.

On the question of object mutation, here we're talking about changing
an object to another implementation of the same compile-time type.
This is completely transparent to the rest of the program.  If we can
do it, I think it is a clean functionality to support.