On Fri, 23 Nov 2007 00:05:27 +0530 hemant kumar <[EMAIL PROTECTED]> wrote:
<snip> > > Yep, I get that, and my comments are no slight to you personally. But, if > > you ever want it to be adopted, then take my advice and stop doing fancy > > stuff. My comments were also more for the Mongrel team since they went > > rushing to your fresh gem too quickly. As I said, if a quick 10 minute > > glance can give me that many warning signs then it's not ready for use. > > Ok zed, its my first gem and that doesn't mean that its of low quality. > Its already being used in couple of my internal company projects. Its > being used in backgroundrb.And I am coding/using it a lot. In a > nutshell, its not offspring of some arm chair design thingy. I needed it > and I coded it. Well, actually I can go even further and give you more advice on how to improve it, but you seem more interested in defending your choices rather than listening. Good luck on it then. > Why one writes open/free software? The main incentive is ( for me > anyways ), so as people use it and generally original coder feels good > about it. So, I do intend to make it possible to run mongrel on top of > packet. But I am just adding 5 methods to core classes man, they are not > big time design thingies, they can be easily removed. Packet doesn't > depend on those 5 methods. Another reason you release code is so that people can give you feedback on it. The second you put it out there it's open for criticism, which is a good thing and you shouldn't get offended by it. I never said "Hemant is a shitty coder." I said, "Hemant's Packet isn't that great, don't use it yet, here's exactly why." Once you understand the difference between the two you'll be able to take criticism of your code much better. It also means that you have room to improve, and you just have to keep hacking on it. Rather than get upset, make it better. <snip> > > > > The rest of my comments still stand though. Keep working on Packet, but my > > suggestion is for you to go back and make it cleaner, smaller, include less > > external code, rely on less, and don't do monkey patching so much. > > Again, Zed, 5 methods. There is not so much of monkey patching as you > mention. And I am trying to make it as clean and lean as possible. > Look into code, send some patches if you feel something is dirty or can > be improved. You are not reading carefully so I'll break it down a little simpler, and then hopefully you'll understand. After that, you're on your own. I don't throw pearls before swine. 1) Rails has these same or similar monkey patches. 2) Ruby has no way to version or select which monkey patch to use, and doesn't warn you. 3) Ruby's primary rule is Principle Of Least Surprise. 4) If you have your monkey patches in a system running Rails (which will happen under Mongrel) then your methods will clash with Rails' methods. SURPRISE! 5) If you have your monkey patches in a system NOT RAILS then your methods will piss people off because SURPRISE! they aren't expected. 6) If Rails changes the signature or behavior of their methods then your's will override and people's code will break. 7) When people's code blows up, they'll have no idea where the offending methods are coming from: Packet, Mongrel, Rails, Facets, Og, Nitro, Camping, Merb, Sinatra, or their own code. **) They are not needed and the benefit does not outweigh the disadvantage given above. Same goes for your class attribute stuff. It's unexpected in a library that low level. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
