I await your pull request on the documentation. We had the discussion about implementing the documented behaviour five years ago, and while it would be preferable in retrospect, there has been no compelling reason for change which has arisen during that time. I am not of the view that code should be changed purely for religious reasons; stability is more important than change for change's sake.
make polyglot optional, as documented
the docs indicate that polyglot is optional. from http://treetop.rubyforge.org/using_in_ruby.html
In order to use Polyglot dynamic loading of .treetop or .tt files though, you need to require the Polyglot gem before you require the Treetop gem as Treetop will only create hooks into Polyglot for the treetop files if Polyglot is already loaded. So you need to use:
require 'polyglot' require 'treetop'
in order to use Polyglot auto loading with Treetop in Ruby.
I for one would prefer the documented behavior. However, I can see that in the treetop gem on my system, Polyglot is required by default. Messing with Kernel#require by default smells like bad practice.
In my case, I need treetop as a dependency for json_select. I have no need for treetop otherwise, or dynamic loading of .tt files. But now when I'm debugging require issues in my project, I've got to consider if polyglot's require is behaving differently from Kernel's require.
In any case, at the very least, the docs should be updated to match the actual behavior.
- 点赞 评论 复制链接分享
- weixin_39588445 5月前
there has been no compelling reason for change
stability is more important than change for change's sake.
This isn't change for change's sake. There is a compelling reason -- namely that gems should not be clobbering or otherwise changing core Ruby behavior. For you to deny this is to uphold the view that gems can and should change core Ruby behavior -- that there is no bright line here. For me, there is a bright line, and it has been crossed. I am ok with crossing that bright line in an exceptional situation, but I don't see that here.
I am firmly of the opinion that overloading Kernel#require is a mistake -- a bug. I don't understand why that would be necessary. Polyglot could still provide the same functionality and use a method name that doesn't clobber core Ruby functionality. It seems a total gee-whiz feature that Polyglot uses use the same letters r-e-q-u-i-r-e to do what it needs to do. I can see how it might be useful for toy projects, where the novelty overwhelms the stink. But all I've got is stink.
If someone really wants to overload Kernel#require, Ruby will give you enough rope to hang yourself, but that doesn't make it a good idea for software engineering in the large.
Given the current Polyglot approach, I'd prefer to never have it installed on any system or project I'm working with. Failing that, I'd prefer to not have it be required. Perhaps I should monkeypatch Kernel#require to NOOP when passed 'polyglot'. /s
Do you really want to defend your gem clobbering core Ruby functionality? Is it possible that this is an actual design/engineering mistake?点赞 评论 复制链接分享
It's five years, and no actual problem reported. Let it go now, ok?
I agree with most of your opinions, and I would not enforce Treetop's use of Polyglot again - yes, it was a mistake - but that's the way it is and you opinions are not sufficient reason for change. You say, in the same sentence "There is a compelling reason, that gems should not..." - is it possible you cannot see the illogic in that statement? The word "should" implies the contrary of compulsion.
If you don't like hooking require, I assume you don't use Rails, on principle, am I right?点赞 评论 复制链接分享
- weixin_39588445 5月前
Fair enough. I do disagree with some of the Rails design decisions and prefer other web frameworks. But Rails gets a little bit of a pass because it's creating an entirely new, comprehensive execution environment. It's not a utility gem like json_select or treetop, where messing with core functionality isn't justified. I do appreciate your time and thoughts on this matter.
I do think the docs should be updated. You might not like my pull request in this respect, should I make it ;)
Cheers, Rick点赞 评论 复制链接分享
I'd be happy to consider a documentation pull request, though I'd prefer not to have to edit it to remove opinions :)点赞 评论 复制链接分享