[Cuis] Cuis-Features

[Juan Vuletich]

Hi Ken,

On 7/5/2013 1:15 PM, Ken Dickey wrote:
> On Fri, 05 Jul 2013 10:35:16 -0300
> Juan Vuletich<juan at jvuletich.org>  wrote:
>
>> This is just great. I want to integrate it into Cuis, and make packages
>> know about this.
> That would be super.
>
>> Something that is not clear to me, is if a package might implement more
>> than one feature. I'd think yes, but then FeatureSpec 'provides' needs
>> to be a collection. In addition, we have several version.revision number
>> in a package, one for each feature it provides. This also means that we
>> might need a version.revision for the package too. But I don't want to
>> make it more complicated than needed. Thoughts?
> I thought about packages providing multiple features.  One of the hard lessons I learned from eXtreme Programming is "You ain't gonna' need it."
>
> Building general facilities with options for foreseeable contingencies is a habit which we get into as designers and is hard to break.

Yes. The "late bind everything" applied to requirements. I agree. In the 
long term, a simple design is always easier to evolve into whatever is 
later needed (for sure not what we had imagined before...).

> Cuis is all about being as simple (but powerful) as we can be, yes?
>
> I really think a single package name and a single feature name, hopefully the same name, should work.
>
> It is always easy to make things more complex when a compelling need arises.

Agreed. Thanks.

>> BTW, the requirements should be specified as featureName + version,
>> without including revision number. Do you agree?
> No, but perhaps we are "agreeing loudly".  It I think about Cuis 4.1 with "41" as the version of Cuis-Base, there were a lot of changes between revisions.  Some of my code would not have worked before a specific revision.

Cuis doesn't follow Semantic Versioning. I like the idea, but Cuis still 
changes too much for that. Maybe some time we get there... Right now, 
specifying a Cuis-Base version is either too limiting (if done strictly) 
or too risky (if done ambiguously). I think we can't specify dependence 
on Cuis-Base versions yet.

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).

> 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 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.

> BTW, I am very much looking forward to loading packages by
>    (Feature named: #Ropes) require.
> rather than:
>     | slash |
>      slash := FileDirectory slash.
>      CodePackageFile installPackageStream:
>          (FileStream concreteStream readOnlyFileNamed:
>              '..', slash, 'Cuis-Ropes', slash, 'Ropes.pck.st'
>          )
>
> Cheers,
> -KenD

:)

Cheers,
Juan Vuletich