We closed the Rails wiki a while back, wikis rarely work in the long term and I have a series of reasons why to avoid wikis maintained outside the project as official documentation.
The documentation of a project belongs to the project and has to evolve alongside the source code. Everything has to move forward in sync. That's why we have everything in Git and patches must update code, tests, and docs to be complete. If there is a bug we should fix it, but I am with José and I think this particular use case needs no documentation: you just can't grab a random file from some lib just because it is available from the load path and expect it to be self-contained. And the lib does not need to document which files work and which don't. *Unless* specified otherwise, when you use a lib you load first its main file. In Ruby in addition you tend to do that because as anyone who have maintained a non-trivial Ruby library knows writing self-contained files that do not depend on load order execution is a fucking nightmare. It is basically impossible to get right because when you miss something the interpreter does not (and has no way to) warn you. So to play safe and to avoid repeating common things a hundred times you balance being extra careful and factoring common things out to the entry points. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
