2009/2/23 Thomas Enebo <Thomas.Enebo / sun.com>

> Yehuda Katz wrote:
>
>> Can you explain *why* you don't like it?
>>
>> Keep in mind that most people would never use this feature... it's mostly
>> for frameworks to be able to make core extensions for their own use without
>> polluting the global space.
>>
> Famous last words...One poignant blog entry can undo your statement in a
> heartbeat.
> My quick take...
>
> The good:
>  - Clearly demarcated syntax to express that you are changing behavior.
>  Much more visible than monkey patching.
>  - It is lexically defined.  Your semantic change only affects the code it
> is surrounding.  The scope of the changes will not seep everywhere.  Though
> I suspect you may end up with a boilerplate at the top of every file in your
> library.
>
> The bad:
>  - This mostly just seems like monkey-patching defense to me.  Maybe you
> are fighting the symptom and not the problem by adding this?  Not sure I
> have much more to add to this...Redefining methods in Ruby is a reality and
> a powerful tool.  I think you are just trying to counter-balance it so
> library authors can prevent users from changing your libraries behavior.


Nope. It's perfectly fine for users to change my library's behavior if they
want to. However, this is not the real-life problem we are facing. The issue
is not that someone wants to change how camel_case works inside of Merb,
it's that they want to change how camel_case works in different code.


> Though you cannot really prevent users from doing anything right?  They can
> still modify Merb::String to do the things you were trying to prevent in the
> first place.    Maybe that is ok, but it still feels like if someone wrecks
> the API you are consuming (String for example), then they may feel the need
> to wreck your version of string also.  Perhaps then they deserve it....then
> again they deserved it the second they ruined String.


They can still change String however they want, and Merb::String would win
inside of Merb's library code.


> I feel pretty ambivalent about this...
> -Tom
>
>
>
>


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325