Cuis-Features

I did a design-sketch/prototype of software Features (Provide/Require) for Cuis.

        https://github.com/KenDickey/Cuis-Features

Just to see if anyone thinks such a thing might be useful.


Very lightly tested.  Try:

        (RequiresFeatureSpec name: #Sound) require.

This should load packages Compression, Graphics-Files-Additional, and Sound in that order.


Rather than making changes to the package structure I added a small dictionary with the provides/requires info and pretend to read it from the package.  

A lot of details to fill in if it seems useful.  


You can add your package dependencies to
        FeatureSpec class>>initializeTemporaryTestScaffold
and re-initialize the class to try out your own stuff.

Morphic-Games-Solitaire requires #'Graphics-Files-Additional'
So:
        (RequiresFeatureSpec name: #'Morphic-Games-Solitaire') require
autoloads Compression, Graphics-Files-Additional, and Solitaire.


Try it out.  If nothing else, you can require #Test.


Cheers,
Ken [dot] Dickey [at] whidbey [dot] com
-------------------
Q: What use is it?
A: What use is a baby?  It may grow up to be somebody.


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

On Thu, 27 Jun 2013 20:17:27 -0700
Ken Dickey <[hidden email]> wrote:
...
> Try it out.  If nothing else, you can require #Test.

Sorry.  That should be #Tests.  

I just pushed the fix.


Hey, I said it was 'lightly tested'.  8^}   8^O   8^|

Ken [dot] Dickey [at] whidbey [dot] com

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

Wow! This is just great!

Thanks, Ken. I haven't tried it yet, but it really looks like what we
need. I'll try to add the provides / requires info to the package files,
and integrate the code.

I'm really happy!

Cheers,
Juan Vuletich

On 28/06/2013 12:17 a.m., Ken Dickey wrote:

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

One thing about "thinking out loud" with prototypes.  The naming is not quite as clear as I would like.

One thought is to rename

 RequiresFeatureSpec -> RequiresSpec
and
 SuppliesFeatureSpec -> SuppliesSpec

Better names?  Other thoughts?

-KenD
--
Ken [dot] Dickey [at] whidbey [dot] com

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

On 6/29/13, Ken Dickey <[hidden email]> wrote:
Ken, could you give a one sentences definition for RequiresSpec and
SuppliesSpec?

I as well think we need good names.

RequiresSpec is a compound word of a verb and an noun.

I would try to have nouns as class names and verbs for methods.

Ideally expressions using these classes should should sound like
regular English sentences.

So maybe we can work on the expressions as a whole (Class name plus
class side selectors).

--Hannes




> -KenD
> --
> Ken [dot] Dickey [at] whidbey [dot] com
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

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

On Sun, 30 Jun 2013 12:47:40 +0000
"H. Hirzel" <[hidden email]> wrote:

> RequiresSpec is a compound word of a verb and an noun.


Ah.  Silly me.  Thank you so much.  I have used so many random programming languages that I forget the basics.

How about:
  A FeatureSpec consists of a Feature and a collection of Requirements.

So:
  RequiresFeatureSpec -> Requirement
  SuppliesFeatureSpec -> Feature
  ProvidesRequiresSpec -> FeatureSpec


Suggestions for better names?

Thanks again,
-KenD


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

So your initial

  (RequiresFeatureSpec name: #Sound) require.

would become

   (Requirement name: #Sound) require.

What about

   (Requirement named: #Sound) require.

?

And how could this expression made different without having two time
'require' in it?

How would expressions with #Feature and #FeatureSpec look like?

--Hannes




On 6/30/13, KenD <[hidden email]> wrote:
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

On 30 June 2013 17:03, H. Hirzel <[hidden email]> wrote:
I'm not sure what "(Requirement named: #Sound) require" means. What about

    (Feature named: #Sound) requires: #(Foo Bar)

or

    Feature named: #Sound requires: #Foo

frank

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

On 6/30/13, Frank Shearar <[hidden email]> wrote: +1
This statement is straightforward and easy to read and write.
Ken, could your system of pulling in features made to work with this
type of statements?




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

On Sun, 30 Jun 2013 18:41:53 +0000
"H. Hirzel" <[hidden email]> wrote:

> >     (Feature named: #Sound) requires: #(Foo Bar)
> >
> > or
> >
> >     Feature named: #Sound requires: #Foo
> +1
> This statement is straightforward and easy to read and write.
> Ken, could your system of pulling in features made to work with this
> type of statements?

Actually, I went the other way.  I'll do a "git push" presently.

I must to admit that I was in a hurry in the first pass and "did not have the time to make it shorter".


I simplified to 2 classes: FeatureSpec and Feature.

One now writes:
   (Feature named: #Sound version: 1 revision: 0) require.

The rationale is that the data structure is for inclusion in packages and one really wants a user to specify version and revision, so I removed the short form.

All feedback welcomed!

--
KenD <[hidden email]>

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

Hannes,

I want to thank you very much for your questions.

I think my brain sometimes freezes like a deer in the headlights.

You got it going again.


Thanks for being gentle with me.


Cheers,
-KenD
--
Ken [dot] Dickey [at] whidbey [dot] com

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

Hi Ken,

This is just great. I want to integrate it into Cuis, and make packages
know about this.

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?

BTW, the requirements should be specified as featureName + version,
without including revision number. Do you agree?

I might have a few hours this Saturday for this. It would be cool to
agree on these details, so I can proceed. If anyone wants to talk, I'm
jvuletich at Skype. I'm not always online, and usually can't talk during
work hours, but feel free to connect and text chat anytime.

Cheers,
Juan Vuletich

On 6/30/2013 6:58 PM, KenD wrote:

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

On Fri, 05 Jul 2013 10:35:16 -0300
Juan Vuletich <[hidden email]> 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.  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.

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

Many packages are/will-be simple and requiring revision 0 is fine forever, but some will be complex enough that revision matters.  [IMHO]

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.


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
--
Ken [dot] Dickey [at] whidbey [dot] com

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

Hi Ken,

On 7/5/2013 1:15 PM, Ken Dickey wrote:
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.

:)

Cheers,
Juan Vuletich

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

On Fri, 05 Jul 2013 14:26:15 -0300
Juan Vuletich <[hidden email]> 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
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

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

On Fri, 5 Jul 2013 17:46:34 -0700
Casey Ransberger <[hidden email]> wrote:

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

Right.  Specifically,

 (Feature name: #'Morphic-Games-Solitaire' version: 1 revision: 0) require.

Loads
  Compression
  Graphics-Files-Additional
  Morphic-Games-Solitaire

If after this I invoke:

 (Feature name: #Sound version: 1 revision: 0) require.
 
This only loads
   Sound
because the other requirements are satisfied.

> Next question: have you guys thought about a UI for this?

What about the Code Browser?

How about "converting" a Category Name into a package?

Select the category, right-click to bring up the context menu, select "Make into Package" and get a version 1 revision 0 <category-name>.pck.st file.

The Package Manager could show a Provides version.revision column.  Select the package to increment a version number or add one or more requirements.  Alternately, one might multi-select packages to create a requirements set, then select the package which needs them.

Just a thought.  Juan is the guy here.


> Ken, this is really cool.

Hey, Cuis is really cool.  I'm just trying to keep the breeze blowing in the right direction.  ;^)

--
Ken [dot] Dickey [at] whidbey [dot] com

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

On 7/5/13, Ken Dickey <[hidden email]> wrote:
+1

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