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

stubble limitations



There is a limitation with the current semantics of stubble that I
don't think I can get around by rearranging the class structure. It
has to do with forking off proxy classes at various levels of the
hierarchy in the presence of abstract classes with non-deferred
methods. In one address space the class hierarchy would look like:

	Waldo			"basic manipulation protocol"
	    IndexedWaldo	"adds table-like access"
		Map		"uses only IndexedWaldo protocol"
		IDSet		"adds set-like protocol for IDs"
		UserTable	"some user waldo"
	    Doc			"has a link space"
		TextDoc		"adds a text space"
		UserDoc		"adds some other kind of space"

In a split address space it wants to be something like:

	Waldo-
	    IndexedWaldo-
		IndexedWaldoProxy#
		Map*		"frontend gets IndexedWaldoProxy"
		IDSet*
		    IDSetProxy#
		UserTable#
	    Doc-
		TextDoc*
		    TextDocProxy#
		UserDoc#

- abstract
* back end instances only
# front end instances only

All of the abstract classes have methods that actually do things,
using the object's own abstract protocol, and these should be
inherited by front end & back end classes. Waldo even has an instance
variable that both sides need (but proxies don't).

This does not jibe with stubble as it now stands. I think the
following will fix the problem, although the semantics are much less
clean. A proxy object can receive three kinds of messages: proxy (send
them along to the other side), censored (blast if you get them), and
inherited (from your superclass on this side). You must be able to
suppress sending instance variables along with the proxy object, such
as the Waldo instance variable that holds onto the manipulator it is
wrapping.

This will work with normal use, but can still blow up if you do
fooProxy->Foo::bar() where bar is suppressed or proxy, since you will
then be executing code that refers to garbage instance variables.
There is no way that the compiler could even know, since fooProxy is
declared as type Foo; it just happens to be a FooProxy at runtime.
	--ravi

P.S. I will actually have to generate proxy classes and methods in
Smalltalk, just like stubble does. It might even be possible to make
it translatable.