Support pot output. #395

Merged
merged 1 commit into from Apr 26, 2012

Projects

None yet

4 participants

@kou
kou commented Oct 13, 2011

This change adds pot formatter.

Here is a sample transcript:

% ruby -I lib bin/yardoc --format pot --output po lib/**/*.rb
Files:         135
Modules:        37 (    5 undocumented)
Classes:       148 (   32 undocumented)
Constants:      62 (   25 undocumented)
Methods:       680 (   78 undocumented)
 84.90% documented
% head po/yard.pot
# YARD::ROOT
#: ../lib/yard.rb:4
msgid "The root path for YARD source libraries"
msgstr ""

# YARD::TEMPLATE_ROOT
#: ../lib/yard.rb:7
msgid "The root path for YARD builtin templates"
msgstr ""

Translators generates #{LOCALE}.po from yard.pot. For example, here is a transcript that generates ja.po from yard.pot:

% LANG=C msginit --locale ja --input po/yard.pot --output po/ja.po
The new message catalog should contain your email address, so that users can
give you feedback about the translations, and so that maintainers can contact
you in case of unexpected technical problems.

Is the following your email address?
  kou@clear-code.com
Please confirm by pressing Return, or enter your email address.
kou@clear-code.com
Retrieving http://translationproject.org/team/index.html... done.
A translation team for your language (ja) does not exist yet.
If you want to create a new translation team for ja, please visit
  http://www.iro.umontreal.ca/contrib/po/HTML/teams.html
  http://www.iro.umontreal.ca/contrib/po/HTML/leaders.html
  http://www.iro.umontreal.ca/contrib/po/HTML/index.html
po/yard.pot:10858: warning: The following msgid contains non-ASCII characters.
                            This will cause problems to translators who use a character encoding
                            different from yours. Consider using a pure ASCII msgid instead.
                            YARD is a documentation generation tool for the Ruby programming language.

                            It enables the user to generate consistent, usable documentation that can be

                            exported to a number of formats very easily, and also supports extending for

                            custom Ruby constructs such as custom class level definitions. Below is a

                            summary of some of YARD's notable features.
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10858: invalid multibyte sequence
po/yard.pot:10868: warning: The following msgid contains non-ASCII characters.
                            This will cause problems to translators who use a character encoding
                            different from yours. Consider using a pure ASCII msgid instead.
                            Feature List
                            ------------

                            **1. RDoc/SimpleMarkup Formatting Compatibility**: YARD is made to be compatible

                            with RDoc formatting. In fact, YARD does no processing on RDoc documentation

                            strings, and leaves this up to the output generation tool to decide how to

                            render the documentation.

po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10868: invalid multibyte sequence
po/yard.pot:10880: warning: The following msgid contains non-ASCII characters.
                            This will cause problems to translators who use a character encoding
                            different from yours. Consider using a pure ASCII msgid instead.
                            **2. Yardoc Meta-tag Formatting Like Python, Java, Objective-C and other languages**:

                            YARD uses a '@tag' style definition syntax for meta tags alongside  regular code

                            documentation. These tags should be able to happily sit side by side RDoc formatted

                            documentation, but provide a much more consistent and usable way to describe

                            important information about objects, such as what parameters they take and what types
                            they are expected to be, what type a
method should return, what exceptions it can 
                            raise, if it is deprecated, etc.. It also allows information to be better (and more 
                            consistently) organized
during the output generation phase. You can find a list
                            of tags in the {file:docs/Tags.md#taglist Tags.md} file.
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10880: invalid multibyte sequence
po/yard.pot:10889: warning: The following msgid contains non-ASCII characters.
                            This will cause problems to translators who use a character encoding
                            different from yours. Consider using a pure ASCII msgid instead.
                            YARD also supports an optional "types" declarations for certain tags.

                            This allows the developer to document type signatures for ruby methods and

                            parameters in a non intrusive but helpful and consistent manner. Instead of

                            describing this data in the body of the description, a developer may formally

                            declare the parameter or return type(s) in a single line. Consider the

                            following Yardoc'd method:

po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10889: invalid multibyte sequence
po/yard.pot:10925: warning: The following msgid contains non-ASCII characters.
                            This will cause problems to translators who use a character encoding
                            different from yours. Consider using a pure ASCII msgid instead.
                                 # Reverses the contents of a String or IO object. 
                                 # 
                                 # @param [String, #read] contents the contents to reverse 
                                 # @return [String] the contents reversed lexically 
                                 def reverse(contents) 
                                   contents = contents.read if respond_to? :read 
                                   contents.reverse 
                                 end

                            With the above @param tag, we learn that the contents parameter can either be
                            a String or any object that responds to the 'read' method, which is more

                            powerful than the textual description, which says it should be an IO object.

                            This also informs the developer that they should expect to receive a String

                            object returned by the method, and although this may be obvious for a

                            'reverse' method, it becomes very useful when the method name may not be as

                            descriptive.


                            **3. Custom Constructs and Extensibility of YARD**: YARD is designed to be 
                            extended and customized by plugins. Take for instance the scenario where you 
                            need to document the following code:


                                class List
                                  # Sets the publisher name for the list.
                                  cattr_accessor :publisher
                                end

                            This custom declaration provides dynamically generated code that is hard for a
                            documentation tool to properly document without help from the developer. To

                            ease the pains of manually documenting the procedure, YARD can be extended by

                            the developer to handle the `cattr_accessor` construct and automatically create
                            an attribute on the class with the associated documentation. This makes

                            documenting external API's, especially dynamic ones, a lot more consistent for
                            consumption by the users.

po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10925: invalid multibyte sequence
po/yard.pot:10942: warning: The following msgid contains non-ASCII characters.
                            This will cause problems to translators who use a character encoding
                            different from yours. Consider using a pure ASCII msgid instead.
                            YARD is also designed for extensibility everywhere else, allowing you to add
                            support for new programming languages, new data structures and even where/how
                            data is stored.

                            **4. Raw Data Output**: YARD also outputs documented objects as raw data (the

                            dumped Namespace) which can be reloaded to do generation at a later date, or

                            even auditing on code. This means that any developer can use the raw data to

                            perform output generation for any custom format, such as YAML, for instance.

                            While YARD plans to support XHTML style documentation output as well as

                            command line (text based) and possibly XML, this may still be useful for those
                            who would like to reap the benefits of YARD's processing in other forms, such

                            as throwing all the documentation into a database. Another useful way of

                            exploiting this raw data format would be to write tools that can auto generate
                            test cases, for example, or show possible unhandled exceptions in code.

po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence
po/yard.pot:10942: invalid multibyte sequence

Created po/ja.po.

Those warning messages are caused by "U+2028" (LINE SEPARATOR) characters in README.md. LINE SEPARATOR isn't included in ASCII charset.

@lsegal
Owner
lsegal commented Oct 14, 2011

Great! Note that I will be releasing 0.7.3 this weekend and this will not be merged into the mainline until then. There are some Ruby 1.9.2/1.9.3 compat fixes that need to go out first, and this stuff isn't ready to ship. We will target the 0.8.0 release for this feature.

@lsegal
Owner
lsegal commented Oct 14, 2011

FYI I've removed those U+2028 characters in the README, no idea how/why they got in there.

@yasuhito
yasuhito commented Apr 4, 2012

+1

@kou kou pot: add "yard i18n" command that generates .pot
YARD::CLI::I18n inherits YARD::CLI::Yardoc because "i18n" command
use the same options in "doc" command. But it will be better that
we share the same options in another way because "i18n" command
doesn't need all options in "doc" command.

We need to discuss how to implement it. So I use inheritance for now.
690b699
@kou
kou commented Apr 11, 2012

I implemented pot output feature by "yard i18n" command followed by discussion on ML: https://groups.google.com/forum/#!topic/yardoc/J8Dor2gjkq0

YARD::CLI::I18n inherits YARD::CLI::Yardoc because "i18n" command uses the same options in "doc" command. But it will be better that we share the same options in another way because "i18n" command doesn't need all options in "doc" command.

We need to discuss how to implement it. So I use inheritance for now.

@lsegal lsegal merged commit 690b699 into lsegal:master Apr 26, 2012
@lsegal
Owner
lsegal commented Apr 26, 2012

I've merged this because it's a good first step. but a few notes about improvements:

  1. I'd like it if you could move your CLI::I18n subclasses into a YARD::I18n namespace. I'm not a fan of classes inside of classes, organizationally speaking, and it's hard to promote component reuse for these classes if they're inside of a CLI namespace. Presumably someone might want to use the PotGenerator class directly, for instance, and they shouldn't have to go through the CLI. So, I've marked those classes as @private for now so that nobody uses them from that namespace. Once you move them into a more appropriate location, you can remove the @private declaration and we can support them as a public API.
  2. As for tests, it's not necessary to test all of the Yardoc functionality over again unless it has changed. A quick look over seems like there are lots of tests that were copy pasted from Yardoc. We don't need those, so see what you can do about removing tests that don't test direct functionality of the subclass.
  3. Ditto for moving the tests for the inner classes like PotGenerator and Test into their own files. I'm also not a fan of multiple classes in a single _spec.rb file.

None of this is urgent, but it would be nice to have this refactored soon. I want to get 0.8 released ASAP, since we're behind on the milestone. If we can do it before, great. If not, no worries, we can target this for 0.8.1.

By the way, we use inheritance of Yardoc in other places in the CLI, like in Stats, so what you did is not unprecedented. It seems to be the best way to do it for the time being. If we need to refactor, we can do so in the future.

Finally, thank you for this awesome contribution, @kou!

@lsegal
Owner

@kou, do we need this file?

kou replied Apr 27, 2012

Yes. We can't use .yardopts because it includes ChangeLog, LICENSE and LEGAL. They aren't needed to be translated.
Or we may use --exclude ChangeLog --exclude LICENSE --exclude LEGAL options with .yardopts.

Owner

Actually --exclude wouldn't help here, since it only affects the parser part of things. I'm just worried that we'll need to start maintaining lots of different .yardopts files whenever we start adding settings. But I guess it is manageable for now. Thanks for explaining the purpose.

Another reason to #344?

Owner

@trans I don't think so. Putting these files in a .yard directory would solve the symptom, not the root problem. Having the three .yardopts files in the project root doesn't actually bug me, having to maintain all three does. The root problem would still be that we have duplicate data in multiple .yardopts files. Maybe what we need is a way to include options from other files.

@kou
kou commented Apr 27, 2012
  1. I'd like it if you could move your CLI::I18n subclasses into a YARD::I18n namespace. I'm not a fan of classes inside of classes, organizationally speaking, and it's hard to promote component reuse for these classes if they're inside of a CLI namespace. Presumably someone might want to use the PotGenerator class directly, for instance, and they shouldn't have to go through the CLI. So, I've marked those classes as @private for now so that nobody uses them from that namespace. Once you move them into a more appropriate location, you can remove the @private declaration and we can support them as a public API.
  2. As for tests, it's not necessary to test all of the Yardoc functionality over again unless it has changed. A quick look over seems like there are lots of tests that were copy pasted from Yardoc. We don't need those, so see what you can do about removing tests that don't test direct functionality of the subclass.
  3. Ditto for moving the tests for the inner classes like PotGenerator and Test into their own files. I'm also not a fan of multiple classes in a single _spec.rb file.

OK. I'll do them.

None of this is urgent, but it would be nice to have this refactored soon. I want to get 0.8 released ASAP, since we're behind on the milestone. If we can do it before, great. If not, no worries, we can target this for 0.8.1.

I'll be able to do them in a few weeks. So, please release 0.8!

@kou kou added a commit to kou/yard that referenced this pull request Apr 30, 2012
@kou kou i18n: remove duplicated specs
This commit is corresponding to 2. in #395:

  lsegal#395 (comment)

  As for tests, it's not necessary to test all of the Yardoc
  functionality over again unless it has changed. A quick look over
  seems like there are lots of tests that were copy pasted from
  Yardoc. We don't need those, so see what you can do about removing
  tests that don't test direct functionality of the subclass.
0c1b932
@kou kou referenced this pull request Apr 30, 2012
Merged

i18n: remove duplicated specs #523

@kou kou added a commit to kou/yard that referenced this pull request Apr 30, 2012
@kou kou i18n: move YARD::CLI::I18n::* to YARD::I18n::*
This commit is corresponding to 1. and 3. in #395:

  lsegal#395 (comment)

  1. I'd like it if you could move your CLI::I18n subclasses into a
  YARD::I18n namespace. I'm not a fan of classes inside of classes,
  organizationally speaking, and it's hard to promote component reuse
  for these classes if they're inside of a CLI namespace. Presumably
  someone might want to use the PotGenerator class directly, for
  instance, and they shouldn't have to go through the CLI. So, I've
  marked those classes as @private for now so that nobody uses them
  from that namespace. Once you move them into a more appropriate
  location, you can remove the @private declaration and we can support
  them as a public API.

  3. Ditto for moving the tests for the inner classes like
  PotGenerator and Test into their own files. I'm also not a fan of
  multiple classes in a single _spec.rb file.
9dc5912
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment