gethemant at gmail.com
Thu Nov 22 13:35:27 EST 2007
On Thu, 2007-11-22 at 13:10 -0500, Zed A. Shaw wrote:
> On Thu, 22 Nov 2007 14:00:58 +0530
> hemant <gethemant at gmail.com> wrote:
<snip where zed agreed>
> The issue isn't so much hacking the core classes, but rather that the primary project that would use your stuff (Rails) already does this. What happens when they change their monkey patching to be slightly different from your's? That'll cause incompatibilities, and since Ruby's open classes and mixins don't provide any warnings or versioning in this case of clashing-hackery you'd be screwing all the people who use your stuff.
> It also would mess with just about any project that doesn't use or want to use Rails. What about the folks using Facets? I'm sure there's API differences in many of the monkey patching you do, Facets does, and Rails does.
> In general, when you write a low level library like Packet that has to coexist with lots of other bad code, you have to keep it clean and pristine with a minimal of evil.
> Or, you can just design it to not need that. When I looked at it first thing I thought was it screamed of over design and cleverness, which just doesn't work in a project that has to coexist. Read above for more reasons why extending the base interactions of Ruby in your library is really a bad idea.
> 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.
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.
> So for licensing you're good, but watch out for it. When you start borrowing code from other people you can get into trouble if they suddenly change their license, decide to interpret it differently, or just get pissy about how you use it.
Good to get this cleared anyways.But its not like Oracle, taking code
from RHEL. The two files that has been imported from EM, are imported
and done for. One can change the license and whatever shit, I am not
affected by that. Heck, i don't even need those damn classes, they are
mostly used by user level code, packet itself doesn't use it. And they
are also dual licensed under GPL2 and Ruby.
> 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
More information about the Mongrel-users