Package Features

Juan,

Great work factoring down the size of the basic image!


It may be time to re-invent something I have used in various Lisps over the decades: Features (also known as provide-require).

The idea is that each package/library/module has a list of Features it Provides and a list of features it Requires.  These features are either a symbol or a pair of symbol and number (or two)).  

E.g. there might be a TTFont.pck.st which
        provides feature #(TTFont 1.2) and
        requires #(StrikeFont #(Morphic 2.3)).

When TTFont.pck.st is loaded, it's header/manifest is checked and if optional provide/require information is included then it is also checked.  

If the package has required features, these are checked against the global features list.  If all features are present, the package is loaded, otherwise the features are checked for in standard places. Typically a global ordered collection of directory names is kept.  E.g. if I require #StrikeFont, then I would check for <directory>/StrikeFont.pck.st and check that it provides the feature #StrikeFont with the appropriate version.revision.

This can be "pre-flighted" to transitively check that all requirements are satisfied before loading anything.  The transitivity gives the proper load order.

The version.revision number is given with each package which provides a feature.   This is used as follows.  If a feature is required, it optionally specifies a version or version.revision.  The revision is just a number which is incremented with each release.  If required, the provided revision must meet this as a minimum.  The version number is a "compatibility number" which is incremented each time an incompatible interface change is introduced.  If a feature version is required, the provided version cannot be higher than the required version.

There are a number of variations on the provides/requires idea, but it is pretty simple to implement and add to standard UI tools and adds system level coherence/consistence checking.

This keeps the base image small and lets one auto-load desired packages by simply require-ing them.


Sometimes the best way to invent the future is to reinvent it.  ;^)

--
KenD <[hidden email]>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Ken,

All this sounds great! I really like the idea.

The only detail I'd add is that the revision number should be advanced
automatically on package save, and maybe the user should be prompted for
possibly advancing the version number.

Cheers,
Juan Vuletich

On 26/06/2013 11:01 a.m., KenD wrote:

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org