On Wed, Jun 20, 2012 at 3:51 AM, Henry Maddocks <hmaddocks / me.com> wrote:
>
> On 20/06/2012, at 12:23 PM, Avdi Grimm wrote:
>
>> Please do not monkey patch core libraries in gems, unless the *purpose* =
of your library is to add functionality to core, eg a library of extensions=
 like activesupport. Yes, this goes for additions as well as overrides. I c=
annot tell you how many times I've seen a "harmless addition" mess things u=
p in confusing and hard to debug ways.

Right, one should be very careful when messing with core classes.

> <rant>
> While I understand it, I really disagree with this sentiment. Sure monkey=
 patching can cause problems, but so can a lot of things. With great power =
comes great responsibility.
> I really don't like this prevailing view that we should dumb down the lan=
guage to the level of the least skilled developers. Banning unless/else and=
 'and/or', predicates returning true/false, inheritance is bad, etc. This i=
s the wrong approach.
> Instead we should be raising the skills of the developers to enable them =
to use the language to it's fullest.
> </rant>
>
> I think the OP's question has shown the right approach. He understands th=
e dangers so, in an effort to improve his skills, he has asked the question=
, how can he use this technique in a way that will cause the least amount o=
f problems. We should be encouraging this.

I disagree: since OP only asked our support for applying a specific
technique but did not disclose any details about what functionality he
wants to add and why we cannot even judge whether the approach was a
good or bad fit for the problem he is trying to solve.  Could be that
a simple method which receives a String argument was sufficient etc.

Ian, please disclose a bit more detail about what problem you are
trying to solve.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/