Hey, a namsepaces discussoin! (Was: Re: Partitioning the image (was Re: Shrinking sucks!))

Lex Spoon lex at cc.gatech.edu
Sat Feb 12 21:47:26 UTC 2005


Cees's comment about all the different parcels, categories, etc. is
illuminating already.  I've only messed with VW a little bit, and I have
yet to even sort out what all of those things *are*....  It sounds,
though, like maybe namespaces are *too* orthogonal?  Maybe, say, each
category should correspond to a namespace?

Regarding capabilities, I still think its an approach to namespaces, but
that's nitpicking.  It may well be that in an E-like system,you already
have a sufficient namespaces solution.  One item that's interesting is
that you can do one-off imports like this:

	def  foo = somevat->giveMeYourFoo()

This may be common enough to merit syntactic sugar, e.g. the following:

	import somevat.foo
	import somvat.bar as baz

desugars into:

	def foo = somevat->giveMeYourFoo()
	def baz = semevat->giveMeYourBar()


However, you never learn what the other vat calls the variable (or if it
even *is* a variable!).  More interestingly, there would be no way to
important *all* variables from some other vat--there's nothing like the
Java "import java.awt.*".  This may be fine; I seem to have heard some
Java programmers thinking it is bad style, anyway, to import .* .

I wonder how well this basic mechanism works, though, when you try to
link together 100 components into one program.  It seems like there will
have to be a linkage file, that does reams of stuff like:

	def htmlpackage = <...load html package...>
	def wwwbrowser = <...load browser package...>
	....
	wwwbrowser.htmlPackageIs(htmlpackage)
	...

This could be sugared for sure so that it has less redundency, but since
the E model is to *explicitly* link things, I think you'd get stuck with
code like the above.

But then, maybe this can be fixed up in a more convenient way.  It would
be great to ask the E guys if they have thought about "E in the large"
before.

(And I'm rambling too...  It's a cool idea!)


Lex



More information about the Squeak-dev mailing list