A thought occurred to me today that a useful strategy for the refactoring, as well as pulling out gems for specific things like formatters, might be to to try to separate the core domain of Cucumber (parsing and executing features) from the CLI user-interface. We could pull out the core stuff into another gem and leave only the user- interface stuff behind in the actual cucumber gem.
There are a few advantages to this separation: * it would force us to clean up the interface between the user- interface (Cucumber::Cli::*) and the core feature parsing / running stuff, which right now is quite messy. * it would give us a clear place to start writing rdoc: for the core. * it would allow tools like testjour to depend on just the cucumber- core gem, rather than having the UI stuff as well. * it might help people / us to think about building other UIs for Cucumber than the CLI.
On Wed, Oct 14, 2009 at 10:40 AM, Matt Wynne <m...@songkick.com> wrote:
> A thought occurred to me today that a useful strategy for the
> refactoring, as well as pulling out gems for specific things like
> formatters, might be to to try to separate the core domain of Cucumber
> (parsing and executing features) from the CLI user-interface. We could
> pull out the core stuff into another gem and leave only the user-
> interface stuff behind in the actual cucumber gem.
> There are a few advantages to this separation:
> * it would force us to clean up the interface between the user-
> interface (Cucumber::Cli::*) and the core feature parsing / running
> stuff, which right now is quite messy.
> * it would give us a clear place to start writing rdoc: for the core.
> * it would allow tools like testjour to depend on just the cucumber-
> core gem, rather than having the UI stuff as well.
> * it might help people / us to think about building other UIs for
> Cucumber than the CLI.
I like this idea. But let's wait until we have replaced Treetop with
Gherkin. That will require quite a bit of internal refactoring and
things can get messy if we have two parallel refactoring efforts.
Let's call it 0.5 when we have Gherkin. Then we can do what you suggest for 0.6.
rather than being generally "available" separately.
It makes no difference to the organisation of the code at the end of
the day, but I think it's important to the marketing message that it's
a coherent whole, albeit one that's very well organised into distinct
interoperating parts!
> I prefer the monolithic thing, where it would be
> Cucumber (cucumber-cli, gherkin, cucumber-core)
> rather than being generally "available" separately.
If I follow you, you're saying that 'gem install cucumber' should install all the basics required to write and execute a feature from the command line as we do now; under the hood it's really a thin dependancy wrapper to install cucumber-{core,cli} and gherkin, which makes it easy for other gems to just pull in cucumber-core.
+1 for that, and apologies if I've got your intent wrong.
> On Wed, Oct 14, 2009 at 10:40 AM, Matt Wynne <m...@songkick.com> wrote:
>> A thought occurred to me today that a useful strategy for the
>> refactoring, as well as pulling out gems for specific things like
>> formatters, might be to to try to separate the core domain of Cucumber
>> (parsing and executing features) from the CLI user-interface. We could
>> pull out the core stuff into another gem and leave only the user-
>> interface stuff behind in the actual cucumber gem.
>> There are a few advantages to this separation:
>> * it would force us to clean up the interface between the user-
>> interface (Cucumber::Cli::*) and the core feature parsing / running
>> stuff, which right now is quite messy.
>> * it would give us a clear place to start writing rdoc: for the core.
>> * it would allow tools like testjour to depend on just the cucumber-
>> core gem, rather than having the UI stuff as well.
>> * it might help people / us to think about building other UIs for
>> Cucumber than the CLI.
> I like this idea. But let's wait until we have replaced Treetop with
> Gherkin. That will require quite a bit of internal refactoring and
> things can get messy if we have two parallel refactoring efforts.
> Let's call it 0.5 when we have Gherkin. Then we can do what you suggest for 0.6.
Given some of the tickets I have opened, I think it's clear what my
opinion is on the matter: big +1. Especially for alternate UIs.
Greg and I are planning on bringing the pain, err... pair-programming
to Gherkin in the next few days, so hopefully 0.5 won't be (too) far
off.
> If I follow you, you're saying that 'gem install cucumber' should
> install all the basics required to write and execute a feature from
> the command line as we do now; under the hood it's really a thin
> dependancy wrapper to install cucumber-{core,cli} and gherkin, which
> makes it easy for other gems to just pull in cucumber-core.
Exactly! Things "just work" great right now, and I think that it
should stay that way.
> +1 for that, and apologies if I've got your intent wrong.
>> If I follow you, you're saying that 'gem install cucumber' should >> install all the basics required to write and execute a feature from >> the command line as we do now; under the hood it's really a thin >> dependancy wrapper to install cucumber-{core,cli} and gherkin, which >> makes it easy for other gems to just pull in cucumber-core.
> Exactly! Things "just work" great right now, and I think that it > should stay that way.
Yes, that's exactly what I'm suggesting. I'd just like the layers underneath, should you care to look down there, to have clearer separation which will make Cucumber more extensible in the long game.
