Re: A thought on module systems

On 29 August 2010 03:31, Kevin Reid <[email protected]> wrote:
> I think this is an original thought I had about the problem of modules/
> libraries:
>
>   A module (library) is a stateless unum.
>
> Therefore:
>
>   Module loading is obtaining a presence of the unum.
>
>   Module naming is long-term remote object naming.
>
>   Library versioning is an upgrade/protocol-compatibility problem.

By the way, I implemented such a module loading scheme for the ebox demo:

  http://0install.net/ebox.html

For example, the "ebox-edit" example application declares a dependency
on the "ebox-help" library like this:

    <requires interface="http://0install.net/tests/ebox-help.xml">
      <environment insert="" name="help"/>
    </requires>

This causes a loader for the library to be added to ebox-edit's
environment (Scope), so that it can import things using e.g.

  def makeHelp := <help:makeHelp>

The "interface" URI is both the name of the library and a hint about
where to get information about it. Incompatible changes use a
different URI, while backwards-compatible changes just use a different
version number. Versions can be restricted like this:

    <requires interface="http://0install.net/tests/ebox-help.xml">
      <environment insert="" name="help"/>
      <version not-before='1.0' before='2.0'/>
    </requires>

Downloads get shared automatically, so that if two programs happen to
use the same version of the same library, then the library only gets
downloaded and stored on disk once.


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang