[Cuis] A small variation to use provides / requires

Germán Arduino garduino at gmail.com
Sun Aug 25 14:02:25 CDT 2013


HI again!

This sort of discussions/opinions are aproximately the same that happened
and originated Monticello/Metacello/etc.

Each option have its own strengths and weakness but, with the current state
of provides/requieres in Cuis, I still think that is a better approach to
separate the req's from the packages with the code. (I know that this
option have also the drawbacks that you mentioned).

But still I think that I gain flexibility and reuse of the packages,
separating the requirements from the real code packages.

Time will say when we advance to a more complex situations with different
versions of each package, but I really not think that is an easy stuff.

As I've said before, is just an opinion and I will think about a bit more.



Each option have its own strengths and weakness
2013/8/25 Ken Dickey <Ken.Dickey at whidbey.com>

> > .. when I've a package that have several req and at the same time this
> package is a req of more than 1 different package, that at the same time
> might have different req between them and coexist in the same image,...
>
> My recollection of a discussion with Dave Simmons about Smalltalk Agents
> is that one can associate revision information with selector
> lookup/dispatch to allow for multiple, different versions of software to
> run in the same image.  I believe this was done in SmalltalkAgents.
>
> This is very useful when developing so that the debug tools can use the
> old, stable version when debugging new development tools.  [This is also
> done in some Scheme systems].
>
> The current provide/requires allows for this by supplying the version &
> revision information.
>
> It is true that we currently do not make use of this in package checking,
> but the code would be easy to add.
>
> The guide is that we try to do useful things in the most simple way we can
> and then make things more smarter and more complex when and if we need to.
>
>
> Having a package specify its direct requirements helps here.
>
> If one separates the requirement description from the package, then the
> package and its description can get out of synchronization -- the wrong
> version information could be used.
>
> One more thing I have to track and update.  One more thing to go wrong.
>
> This is less of a danger when the description is part of the package.
>
> IMHO, package management is easier.  When I change a package, the revision
> number is incremented so when the package is saved I know it is a new
> revision.
>
> If two packages have conflicting requirements, each package requiring
> other packages with  incompatible versions, then the code can check and
> deal with that.
>
> Incompatible requirements are like missing requirements -- it means that
> you can't safely use the mix of code packages together.
>
> It is much better to know this before the code is loaded, no?
>
>
> It would help me if
>   Feature require: 'Swazoo'
>
> Actually loaded Swazoo...
>
> $0.02
> --
> Ken [dot] Dickey [at] whidbey [dot] com
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



-- 
Saludos / Regards,
Germán Arduino
www.arduinosoftware.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130825/aaf9a07d/attachment-0003.html>


More information about the Cuis mailing list