buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Spiewak" <djspie...@gmail.com>
Subject Re: Interactive Shell Support
Date Mon, 05 Jan 2009 23:30:24 GMT
Conceptually, shell:jirb *is* a compound task.  I read that as "in the shell
namespace, execute the jirb task".  It isn't logically parametrized at all,
it just happens to be dynamically created.  The clincher for me is the fact
that the shell:* namespace is finite and well-defined, whereas test
(which *should
be* logically parametrized) has an unfixed domain.

Daniel

On Mon, Jan 5, 2009 at 5:18 PM, Assaf Arkin <arkin@intalio.com> wrote:

> On Mon, Jan 5, 2009 at 3:00 PM, Alex Boisvert <boisvert@intalio.com>
> wrote:
> > On Mon, Jan 5, 2009 at 2:55 PM, Daniel Spiewak <djspiewak@gmail.com>
> wrote:
> >
> >> Assaf's parametrized idea seems like the "proper" way to do this, but I
> >> don't like the syntax.  At least to my eye, shell:jirb is *much* nicer
> and
> >> more consistent with the "Buildr philosphy" than shell[jirb].  Besides,
> the
> >> former is marginally easier to type.
> >
> >
> > I feel the same way.   I'm curious to see if many Rake-based projects
> will
> > adopt this new convention.
> >
> >
> >> We could use your multiple-tasks idea without too much hardship in the
> >> implementation.  I've got all the providers in a Hash, so a simple .each
> {
> >> |lang, prov| define_task ... } should be sufficient.  I'm fine with
> doing
> >> it
> >> this way as long as y'all are ok with it.  :-)
> >
> >
> > One precedent I can think of is the form "buildr test:SomeTest", which I
> > like so I'm supportive of following our existing convention.
>
> buildr test:<not task name> was written in the days of Rake 0.7.3,
> it's a hack, painful to maintain and extend.  I've been longed
> convinced its days are over, just didn't get around to do a better
> implementation.
>
> Everywhere else, foo:bar means compound task name, it identifies the
> task being executed.  Not so with test, where the last part is an
> argument telling the test task what to do, but expressed as a task
> name.
>
> Not only is an argument conceptually better, the code to implement and
> test it is much simpler, and you can support multiple arguments.  Say
> we wanted to give test two arguments, the class name and test name.
>
> If you have shell.using(:jirb) in the project definition and
> shell[jirb] on the command line, that looks consistent to me.  One is
> setting default value, the other affecting it by argument.
>
> Assaf
>
> >
> > alex
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message