On Mon, Jan 5, 2009 at 3:14 PM, Daniel Spiewak <[email protected]> wrote: > Implemented in GitHub fork, interactive-shell branch. > > Incidentally, I noticed that a lot of Buildr tasks have documentation right > in the code. Is this the correct way of doing things? More specifically, > Assaf wants the framework documented, so where should that go?
Usage instructions go in doc/pages, everything else (mostly API) in the code itself. So if someone wanted to start a shell from the command line, they'd read about it in the guide. If they wanted to create a new shell, they'd lookup the API documentation for Buildr::Shell (or whatever other module/class). Assaf > > Daniel > > On Mon, Jan 5, 2009 at 5:00 PM, Alex Boisvert <[email protected]> wrote: > >> On Mon, Jan 5, 2009 at 2:55 PM, Daniel Spiewak <[email protected]> >> 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. >> >> alex >> >
