Hi Stephen!

Stephen Pair <stephen at pairhome.net> wrote:
[SNIP]
> >But what are the advantage of these names and these requires clauses? I
> >would like to understand that.
> 
> In order to enumerate the advantages, I have to know what I'm comparing 
> it against.  How else would you declare that a package has a 
> prerequisite?  It is these names that *do* appear within a package 

Well, I just intend to be able to attach an SMResource to
SMPackageReleases. There is nothing at all inside the package itself. It
can still be just a .cs.gz.

Perhaps I am... daft. :-)

> version.  It is the configuration that binds these names to specific 
> versions of specific packages.  You have to have some way of declaring 

Yes, I understood the separation of names on one side and specific
packages+versions on the other.

> that a dependency exists (and you need to allow the list of dependencies 
> to change from version to version). 

Yes, but since I just attach an SMResource to an SMPackageRelease
(please note that when I write SMPackageRelease I mean a specific
version, otherwise I write SMPackage).

And when I do a new SMPackageRelease of this package I attach another
(possibly a copy) SMResource to that one.

Sidenote: An SMResource is either external with a URL pointing at it or
internal to the map and then it actually contains a String as its
content. That could then be whatever you like that you can represent as
a String. And no - not an object because then we would need classes for
them yaddayadda. A String will have to do.

> For example, KomServices 1.0 has a prerequisite called 
> "DynamicBindings"...based on feedback I've received, I'm going to remove 
> that pre-requisite in version 1.1 of KomServices.  Therefore, I need a 
> way of specifying that version 1.0 does have this prerequisite called 
> "DynamicBindings", whereas version 1.1 does not.  The name of a 
> pre-requisite is arbitrary...I didn't have to call the pre-requisite 
> "DynamicBindings"...I could have called it whatever I wanted...the point 
> is that there exists this notion of a prerequisite to something that 
> provides dynamic bindings like functionality that exists in 1.0 and is 
> being removed in 1.1.

But... isn't that because you have some form of internal mechanism
inside your SAR? Isn't that the *real* reason for this separation?

> - Stephen

regards, Göran