Re: E patches for review: ELoader
Thomas Leonard <tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]>
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Organization | IT Innovation |
| Message-ID | <[email protected]> |
Here are some cleaned-up patches for adding ELoader. There are four in the series (on my "proposed" branch): http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commits/proposed They are: "Added <elang:interp.ELoaderAuthor>" http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/1c03d05489a596a474bd87d3ccdb6deee7819714 "Added seedVat/3 to give envExtras to the new vat" http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/fcfa012324148163edc33f7a34a6de0f64d74d66 "When running (unconfined) code with rune, give it a <this> loader by default" http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/6e8e15eaf64d423d749bf66ce37533ec44e50854 "Set <this> loader when running updoc scripts" http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/2f18c1519028a755f0fe6c1349ae914961ff2066 I agree with Kevin that a full module system needs more than this. In particular, the ability to have public and private APIs for modules. However, I think this would build on these patches rather than replace them. The code above never connects modules together itself; it just gives a single <this> loader to .e and .updoc scripts. Programs wanting to use multiple modules (e.g. my prototype) make a loader for each module and connect them themselves. They can choose whether to give a module its dependency's <this> loader directly, or some restricted facet of it. Note: seedVat is still using the persistence sealer to transfer the loader configuration between vats. This isn't a security issue because seedVat already gives the caller <unsafe> in the new vat. I'm not sure there's much advantage to using a different sealer; I think it would just make it less likely that existing objects can be copied successfully. It's up to the programmer not to copy an object that shouldn't have two instances at once, just as they shouldn't revive two vats from a single state file. I don't feel strongly about it either way, though. -- Dr Thomas Leonard IT Innovation Centre 2 Venture Road Southampton Hampshire SO16 7NP Tel: +44 0 23 8076 0834 Fax: +44 0 23 8076 0833 mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected] http://www.it-innovation.soton.ac.uk