I’m working on cucumber-python. (Currently in a private repo…not ready yet, but soon!) Along the way, I started out by simply converting microcuke into the Python equivalent. Now I’m fleshing out the implementation to be a proper command-line tool.
Microcuke has mostly fulfilled its purpose as a minimal reference implementation very well. While using it as a reference, however, there have been a few bumps. (I noted one bump in #8, which is that EventEmitter can be tricky to port to other languages.) Here, I would like to point out some issues with the pretty_plugin module.
Issues
The PrettyPlugin class name
Despite its name, the PrettyPlugin class doesn’t actually function like a plugin. There is no plugin system. As an implementor ports microcuke to their language of choice, after they
No colorless printing
Furthermore, there is no “NonPretty” equivalent. I love colors, and they should be the default for any modern command-line program. However, the lack of a colorless printer in microcuke has created more work for me. I am now refactoring most of the pretty_plugin module.
This is because, once I started on the command line interface in cucumber-python, I used cucumber-ruby as a reference (since microcuke has no CLI). One of the options is --no-color. There is no way of turning off colors in microcuke, so now I have to write a colorless printer as a baseline. Then I have to think about the best way to connect it to a color printer, which I haven’t determined yet.
Even though modern command line programs should have colors on by default, I think it is good practice for them to play nice with other command-line programs, too—and that means the ability to disable colors. That way we don’t have to anticipate how the output might be used—colors are only useful for humans reading the terminal, after all.
Proposed Solution
I think a good solution to the above would be:
- Create a
SourceFormatter class
- It is instantiated with an arbitrary set of
options (one of which is a flag for color)
- Calls to methods accept input, and return formatted strings
- …And in fact, all it does is return formatted strings. It does not print.
- The
SourcePrinter class uses the SourceFormatter class for all formatting
SourcePrinter manages lines, lineIndex, and performs the actual printing- Before each print,
SourcePrinter sends some text to SourceFormatter, and gets back the string to print
- Depending on
SourceFormatter.options, the strings might include colors…or not. SourcePrinter doesn’t care. It just passes a string to the formatter and prints the result.
I think this is also in the same spirit of microcuke’s design of small, loosely-coupled objects.
Note that, if the proposed changes were made, it suddenly becomes tempting to make some other changes as well:
- With no plugin system in place, perhaps the functionality of
PrettyPlugin should be moved into SourcePrinter?
- If so, then the module named
pretty_plugin.js contains printers and formatters, so the module should probably be renamed to something like output.js.
What do you think?
I’m working on cucumber-python. (Currently in a private repo…not ready yet, but soon!) Along the way, I started out by simply converting microcuke into the Python equivalent. Now I’m fleshing out the implementation to be a proper command-line tool.
Microcuke has mostly fulfilled its purpose as a minimal reference implementation very well. While using it as a reference, however, there have been a few bumps. (I noted one bump in #8, which is that EventEmitter can be tricky to port to other languages.) Here, I would like to point out some issues with the
pretty_pluginmodule.Issues
The
PrettyPluginclass nameDespite its name, the
PrettyPluginclass doesn’t actually function like a plugin. There is no plugin system. As an implementor ports microcuke to their language of choice, after theyNo colorless printing
Furthermore, there is no “NonPretty” equivalent. I love colors, and they should be the default for any modern command-line program. However, the lack of a colorless printer in microcuke has created more work for me. I am now refactoring most of the
pretty_pluginmodule.This is because, once I started on the command line interface in cucumber-python, I used cucumber-ruby as a reference (since microcuke has no CLI). One of the options is
--no-color. There is no way of turning off colors in microcuke, so now I have to write a colorless printer as a baseline. Then I have to think about the best way to connect it to a color printer, which I haven’t determined yet.Even though modern command line programs should have colors on by default, I think it is good practice for them to play nice with other command-line programs, too—and that means the ability to disable colors. That way we don’t have to anticipate how the output might be used—colors are only useful for humans reading the terminal, after all.
Proposed Solution
I think a good solution to the above would be:
SourceFormatterclassoptions(one of which is a flag forcolor)SourcePrinterclass uses theSourceFormatterclass for all formattingSourcePrintermanageslines,lineIndex, and performs the actual printingSourcePrintersends some text toSourceFormatter, and gets back the string to printSourceFormatter.options, the strings might include colors…or not.SourcePrinterdoesn’t care. It just passes a string to the formatter and prints the result.I think this is also in the same spirit of microcuke’s design of small, loosely-coupled objects.
Note that, if the proposed changes were made, it suddenly becomes tempting to make some other changes as well:
PrettyPluginshould be moved intoSourcePrinter?pretty_plugin.jscontains printers and formatters, so the module should probably be renamed to something likeoutput.js.What do you think?