[Cuis] Cuis-Features

[Casey Ransberger]

So if I had a feature B that depended on the presence of a feature A, would
sending #require to B automatically load A as well?

Next question: have you guys thought about a UI for this? I imagine that
this could actually be as easy to use as SqueakMap, but with the dependency
graph information, it's more like the Synaptic package manager in Ubuntu
(apt/dpkg,) or without a (friendly) UI, more or less CPAN :)

Last question: should we use this to build our various images? I hate
building images. It's one of my least favorite things about Smalltalk. I
used to keep a configuration script, but it always ended up being too big a
pain to maintain. This on the other hand looks like it would do the job,
and it's pretty elegant.

Ken, this is really cool.


On Fri, Jul 5, 2013 at 3:50 PM, Ken Dickey <Ken.Dickey at whidbey.com> wrote:

> On Fri, 05 Jul 2013 14:26:15 -0300
> Juan Vuletich <juan at jvuletich.org> wrote:
>
>
> > Cuis doesn't follow Semantic Versioning.
> ...
> > But I think we can agree on using "semantic versioning" like
> > version.revision numbers for packages and Features. Then we'd only
> > indicate dependence on version number (not revision).
>
> I see.  So requirements would not use revisions.  OK by me.
>
> > > Many packages are/will-be simple and requiring revision 0 is fine
> forever, but some will be complex enough that revision matters.  [IMHO]
> >
> > Mhhh. Not sure. To me, asking for SomeFeature-1.0 is not the same as
> > asking for SomeFeature-1.*, as the former is a specific release while
> > the latter matches a whole series.
>
> The prototype code just has version as equal-or-less and revision as
> equal-or-more.  So a revision of 0 is a * but without the cost of pattern
> matching.  For me, revision 0 means any revision greater than or equal to
> zero.
>
> I see that this is not clear from the interface.
>
> > > The constructors could certainly have short forms with the obvious
> default(s).  I would expect the following to be the same invocation:
> > >
> > >    (Feature named: #Sound) require.
> > >    (Feature named: #Sound version: 1) require.
> > >    (Feature named: #Sound version: 1 revision: 0) require.
> >
> > No, to me, default is nil or *, i.e. "anyone will do", while 1 or 0 are
> > specific.
>
> I think I see where you may be heading.
>
> Perhaps using the current interface for fixed (equality) requirement and
> better naming for ranges:
>
>   (Feature named: #MrCool version: 2) "versionEqualTo:"
>   (Feature named: #MsCool versionRange: 1 to: 3)
>   (Feature named: #TooCool version: 3 revisionAtOrAbove: 15)
>   (Feature named: #ImCoolToo versionRange: 3 to: 4 revisionAtOrAbove: 15)
>
> The idea being to avoid the need for a pattern language for
> version/revision specs and hide the details in the implementation.
>
> This would certainly be a more useful/clear interface.
>
> Hey, I would be less confused. ;^)
>
> Cheers,
> -KenD
> --
> Ken [dot] Dickey [at] whidbey [dot] com
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130705/f518473f/attachment-0003.html>