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
|