Sorry.
Not qualified, it is clear to the whole Universe that you don't use Active Record, because you say it at every single opportunity you have. Thank you anyway.
The guide wouldn't be about ActiveRecord, but I got the message.
Before calling something or someone stupid please try to understand the person/project, its historical reasons, its needs.
Talking about something you don’t understand is very easy.
Next time think twice before insulting the project on this list again, or you could not get replies.
I was planning to send a particular message to Xavier about that but it seems he was not the only one offended.
I'd like to apologize about that and I simply forgot to remove that particular opinion from the message. I just copied and pasted my solution and forgot I had written that along the other lines.
It wasn't my intention to publicly offend any of you. I should have re-read my message and removed that "stupid" piece from it if I have noticed it there.
It was intended to be kept only in my private repository as my particular opinion on the subject.
It wasn't meant to offend any of you.
So sorry about that.
I was planning to send a particular message to Xavier about that but it seems he was not the only one offended.
I'd like to apologize about that and I simply forgot to remove that particular opinion from the message. I just copied and pasted my solution and forgot I had written that along the other lines.
It wasn't my intention to publicly offend any of you. I should have re-read my message and removed that "stupid" piece from it if I have noticed it there.
It was intended to be kept only in my private repository as my particular opinion on the subject.
It wasn't meant to offend any of you.
So sorry about that.
Before calling something or someone stupid please try to understand the person/project, its historical reasons, its needs.
Talking about something you don't understand is very easy.
Next time think twice before insulting the project on this list again, or you could not get replies.
-- 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 rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Accepted, thanks for the email.
Thank you for accepting my appologies and for your awesome work on Rails, specially on documentation.
By the way, I has being honest about the guide on using parts of Rails in user applications. If you change your mind about that please let me know.
Accepted too.
About the subject, I think we had a guide or a topic in some guide about how to use Action View outside Rails. I’m not 100% sure but if this guide/section existed we reverted it since we thought doesn’t make sense to leave it as official documentation since it is too advanced and talks more about the Rails internals and how it is implemented, not about how it is used.
I know is hard to understand the Rails internals but I don’t think there are more that we can do that try to answers the people questions.
I wouldn’t mention just ActionView. I believe this approach is used by all major pieces in rails repository, like AR, ActionPack and the like with the exception being AS.
The guide would be something like:
Although I agree it is a nice addition, our guides are more about the conventions. This is configuration.
As everyone know Rails is conventions over configurations. So I prefer to leave it outside our guides.
It is convention over configuration, not convention instead of configuration.
How are we supposed to learn how to configure it?
Some topics are not fit for the guides, it is really about conventions. Regarding configuration we have a guide only to the applications configurations but I don’t think a guide about how to use Rails pieces outside Rails is a good fit to our guide.
The best way to learn about this topic is source diving or asking a someone who know. 
I don’t know what the fuss is about and what needs to be documented.
Most Ruby gems (and even libs inside Ruby) require you to load the top-level file in order to use it properly.
You can’t go around picking whatever you want and expect it to work. Examples:
- Rake does common requires:
https://github.com/jimweirich/rake/blob/master/lib/rake.rb
For example, this file assumes Task is loaded:
https://github.com/jimweirich/rake/blob/master/lib/rake/multi_task.rb
- Rack sets up autoloads:
- Webrick does the same as Rake:
https://github.com/ruby/ruby/blob/trunk/lib/webrick.rb
So saying Rails is “stupid” regarding this requirement shows rather a lack of understanding how most Ruby libraries work.
I agree with José. Is there a tl;dr for this thread?
I think it should be documented, maybe not on guides but somewhere.
I’ve opened a issue about a similar subject in the past assuming that was a bug instead of the expected behavior.
Note that I agree that’s a “advanced topic” but the truth is we need to document it somewhere.
I would be happy to make a blog post about this topic but posts aren’t always found like the official documentation or wiki.
Makes any sense to enable the GitHub wiki?
The GitHub wiki will allow topics like that without making any extra effort from the rails core team who already have a lot of work 
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.
Not to be argumentative,
But I’ve been having a good time lately of making each file require only
what it needs to function on its own. Sometimes I have to require every
file, but most of the time I get to be able to do what rosenfeld likes.
I agree that this kind of documentation is a bit unnecessary,
furthermore I think it’d be better to be considerate of the necessary
collaborators for each given class/file. No change required.
~Spaceghost
You convinced me now.
I didn’t maintained a wiki in a long term so I can’t argue about that.
What you said about picking random files makes absolutely sense, in fact, that was my problem on the issue
Rails components do that, except that you have to load the root file. Because if you grep AR and the blank extension appears 100 times... well, not only that means you are repeating too many require calls, it means from those with the pass of time possibly 5 are no longer necessary, and other 10 are missing. Solution: move loading blank to the main entry point, and do the same with the files grep stats show as the most used.
active_support/rails.rb was defined using source code statistics by the way.
Of course we are talking about using the components standalone, if you have loaded a Rails application then you are/should be golden.