--001636e0ab15f2584a046399fd1c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

--001636e0ab15f2584a046399fd1c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class="gmail_quote">2009/2/23 Thomas Enebo <span dir="ltr">&lt;Thomas.Enebo / sun.com&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Yehuda Katz wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Can you explain *why* you don&#39;t like it?<br>
<br>
Keep in mind that most people would never use this feature... it&#39;s mostly for frameworks to be able to make core extensions for their own use without polluting the global space.<br>
</blockquote></div>
Famous last words...One poignant blog entry can undo your statement in a heartbeat. &nbsp;<br>
My quick take...<br>
<br>
The good:<br>
&nbsp;- Clearly demarcated syntax to express that you are changing behavior. &nbsp;Much more visible than monkey patching.<br>
&nbsp;- It is lexically defined. &nbsp;Your semantic change only affects the code it is surrounding. &nbsp;The scope of the changes will not seep everywhere. &nbsp;Though I suspect you may end up with a boilerplate at the topf every file in your library.<br>

<br>
The bad:<br>
&nbsp;- This mostly just seems like monkey-patching defense to me. &nbsp;Maybe you are fighting the symptom and not the problem by adding this? &nbsp;Not sure I have much more to add to this...Redefining methods in Ruby is a reality and a powerful tool. &nbsp;I think you are just trying to counter-balance it so library authors can prevent users from changing your librariesehavior. </blockquote>
<div><br>Nope. It&#39;s perfectly fine for users to change my library&#39;sehavior 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&#39;s that they want to change how camel_case works inifferent code.<br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Though you cannot really prevent users from doing anything right? &nbsp;They cantill modify Merb::String to do the things you were trying to prevent in the first place. &nbsp; &nbsp;Maybe that is ok, but it still feels like if someone wrecks the API you are consuming (String for example), then they mayeel the need to wreck your version of string also. &nbsp;Perhaps then they deserve it....then again they deserved it the second they ruined String.</blockquote>
<div><br>They can still change String however they want, and Merb::String would win inside of Merb&#39;s library code.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I feel pretty ambivalent about this... <br>
-Tom<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.1325<br>

--001636e0ab15f2584a046399fd1c--