Examples:
In Rails world projects like Kaminari implicitly includes modules to all models. https://github.com/kaminari/kaminari/blob/master/kaminari-activerecord/lib/kaminari/activerecord.rb#L7
Is possible to freeze core Hanami and project classes?
Thereby stimulate community to use explicitly prepend or include, containers or hooks.
[hanami_classes, controllers, models, ...].each do |klass|
klass.freeze
end@amerov Hi and thanks for this proposal.
If you heard me tell that monkey-patching is wrong, I was referring to the abuse against Ruby core classes and stdlib. That is wrong and shouldn’t be used.
However, I don’t consider what you describe as monkey-patching, but as a way to enhance the features of a framework. There is nothing wrong in that. If you add kaminari, it’s because you want to add more capabilities to your active record models.
Freezing classes would stop the growth of an ecosystem around Hanami. So I’m against this proposal.
Hi @jodosha, this is my first time using Discourse and also my first time interacting with Hanami in some way.
First, I’d like to tell you that I’m glad that Hanami exists and that it has an interesting community. Even though I’m not planning on using Hanami myself, I think we share a lot in common and I was trying to find a good place to start some discussion around ruby web applications without Rails so that we could make our community stronger by joining Hanami, Roda, Cuba and Sinatra communities for example. I think we all share a lot in common and having a common place for all of us would be great to make it stronger even though we are using different web frameworks/libraries. Would you be interested in creating such a ruby-web-developers group that wouldn’t be tied to Rails or ActiveSupport? I think we could benefit from such group by asking for what gems others are using to handle general needs such as job processing, mailing, factories, database persistence and so on.
The reason I started this discussion in this topic was this:
“If you heard me tell that monkey-patching is wrong, I was referring to the abuse against Ruby core classes and stdlib. That is wrong and shouldn’t be used.”
I heartedly agree with you on this topic and I guess most other members in this alternative community would agree with that too. I mentioned that as one of the strongest reasons why I switched to Roda last week in two articles:
http://rosenfeld.herokuapp.com/en/articles/ruby-rails/2017-05-01-feeling-alone-in-the-ruby-community-and-replacing-rails-with-roda
http://rosenfeld.herokuapp.com/en/articles/ruby-rails/2017-05-03-ruby-on-rails-the-bad-and-good-parts
This is my attempt on stopping feeling alone in the Ruby community. I want a stronger Ruby community that has other values than the Rails community.
By the way, I noticed that Hanami depends on hanami-mailer which depends on the mail gem. I’m not sure if you noticed but the last release of the mail gem will also patch Ruby core classes. Fortunately it seems those patches have been removed last week, so the next release won’t contain them:
@rosenfeld Hi there 
and welcome!
Absolutely. Which tool for communication you were thinking of?
I read the “feeling alone” last week when somebody shared it on Reddit. A great read 
Yes I spotted it long time ago: Remove monkey-patching? · Issue #936 · mikel/mail · GitHub
But we kept mail because it’s a solid lib, we didn’t wanted to implement a lib from scratch just because of monkey-patching. Of course I’m extremely happy they removed it from the lib.
Thanks 
I wasn’t really thinking about communication tools yet. I guess I’m old school and would probably prefer some google group but this isn’t definitely a decision I have some strong opinion about.
My idea is to check with the community and work with whatever it prefers.
I think the first step would be to check with the other communities (Roda, Sinatra, Cuba, what else?) and see if they would be interested and which tool they would prefer. I’ll try to send an e-mail on their mailing lists and will ask them about this.
I think it would be also a great idea to have some kind of Wiki around this community for newcomers specially. Github Wiki seems to work well enough. My idea would be to explain how to achieve some basic features in Ruby with each framework/library. Things like sending an e-mail, working with JavaScript and other static resources, auto-reloading, databases, background jobs, test frameworks/libraries, factories, dealing with websockets and all those common requirements for web applications. It would make it easier for a newcomer to decide which stack they prefer by taking a glance on how it looks like in each stack.
We could also have framework/library agnostic documentation when it makes more sense, including describing techniques to move an existing project to a new stack and so on. We could simply write those in the Wiki if we can agree on the subject or we could simply link to other external articles on the subject when the opinions would vary a lot. It’s somewhat what would be a an “awesome non-Rails ruby web development”
If you prefer, just let me know your e-mail and I can send a preview so that you can review it before I send the idea to Roda, Sinatra and Cuba mailing lists. Does that make sense?
@jodosha, I just invited the Roda users, let’s see how they will react to it: https://groups.google.com/forum/#!topic/ruby-roda/ruWKEZufg4o
@rosenfeld we can use this forum as well. Regarding the “awesome lists” we have http://awesome-hanami.org/ curated by @davydovanton. We collect over there Hanami based solutions, but in the future I’d love to see also pure Ruby libs.
we already have it (for hanami only) 
Hi @davydovanton and @jodosha,
That’s great, but as I said, it could be even better if we could join the efforts with people that think similar to each other but are using different web frameworks. It would even make it easier for someone who is considering leaving Rails to better evaluate which options suite them best if we can provide information on how to achieve different kind of things on each framework for example.
In that sense, it’s probably easier to get people to cooperate if we host things in a separate organization to avoid directing towards a particular solution.
For example, for those trying to get rid of monkey patches, it’s not quite clear in that awesome list that FactoryGirl and Sidekiq would add such patches for example. My idea would be for us to categorize some libraries so that someone could easily inspect them and decide which solution to adopt for example.
I was thinking about some sort of repository with many markdown files that would be easy to read directly in Github while being easy to publish as Github pages for example for easier reading. And it should be easy for people to contribute to such docs. It should probably belong to some special organization. It could be GitLab as well, it’s just that currently most developers have a Github account already.
And for general discussions we could use some mailing list I guess. I’m still waiting for Roda’s users feedback and tomorrow I’ll try to reach more people from the Sinatra and Cuba communities and see whether or not people would be interest in joining efforts or whether they prefer to keep their own separated communities only.
@rosenfeld Sure, just let us to know how we can help you. We’re in for it.
That’s awesome, @jodosha, thanks! I just created a temporary Google Group so that it would be easier for us to discuss this rather than coordinating several conversations in different existing groups Please subscribe to it and let’s discuss it there:
Google says there is no group named respectful-ruby.
It was renamed to alt-ruby after some discussion. I’m not allowed to post links here though.