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

2009/2/24 Eero Saynatkari <ruby-ml / kittensoft.org>

> Excerpts from brixen's message of Wed Feb 25 00:04:34 +0200 2009:
> > In implementing Rubinius, we have only encountered one major issue
> > with redefining a core library method: mathn changing Fixnum#/.
>
> In addition to overriding, selectors can be used for adding (and,
> if implemented file-/block-wise, deleting.)


Frankly, the proposal is completely unrelated to something you would have
encountered while implementing Rubinius. By definition, the core classes are
globally available, and not suitable for selector namespacing.


> > At least as important (if not more) as seeing what a language feature
> > makes easy is seeing what a language feature makes hard. What will it
> > look like in code when folks inevitable try to work around the fences
> > you erect with your selector namespaces? They will try to work around
> > them.
>

The proposal really does not erect any kind of fences. It establishes some
core extensions for use only inside of a specific file. Nothing stops users
from reopening the namespaces (in the proposal, they are simple modules) and
modifying the methods. Likewise, nothing stops users from using the
namespaces in their own code. There is nothing in the proposal designed to
block users from doing what they want.


> > Engineering software by trying to protect against the invisible,
> > unknowable, purely speculative demons that lurk in some future world
> > leads to horrible languages and even worse software. One of the things
> > Ruby has going for it is some very good software that judiciously
> > changes assumptions made at the time other software/code was written.
>

The proposal is based on real-life problems faced by real-life users using
real-life frameworks. I captured the use-case in the OP (Rails and Merb both
defining String#camel_case), which has actually bitten real users trying to
use Merb with ActiveRecord.


>
>
> I think the two paragraphs contrast a bit :)
>
> However, to offer an alternative consideration, how about a real
> mechanism for "unrequiring" and/or "unextending"? Particularly the
> non-methodwise variants of selector namespaces could very well be
> replaced by being able to (really) activate and deactivate files
> or modules at runtime.


unrequiring is actually more complex of a feature to implement with no
additional benefits that I can see. unextending doesn't solve the problem at
all (except to provide a slow and extremely awkward way to emulate the
feature on an object-by-object basis).

The proposal is actually fairly straight-forward, relatively simple to
implement, and does not introduce any "barriers" for users at all.

--
> Magic is insufficiently advanced technology.
>
>


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

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

<br><br><div class="gmail_quote">2009/2/24 Eero Saynatkari <span dir="ltr">&lt;ruby-ml / kittensoft.org&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1pxolid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Excerpts from brixen&#39;s message of Wed Feb 25 00:04:34 +0200 2009:<br>
<div class="Ih2E3d">&gt; In implementing Rubinius, we have only encountered one major issue<br>
&gt; with redefining a core library method: mathn changing Fixnum#/.<br>
<br>
</div>In addition to overriding, selectors can be used for adding (and,<br>
if implemented file-/block-wise, deleting.)</blockquote><div><br>Frankly, the proposal is completely unrelated to something you would have encounteredhile implementing Rubinius. By definition, the core classes are globally available, and not suitable for selector namespacing.<br>
/div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; At least as important (if not more) as seeing what a language feature<br><div class="Ih2E3d">

&gt; makes easy is seeing what a language feature makes hard. What will it<br>
&gt; look like in code when folks inevitable try to work around the fences<br>
&gt; you erect with your selector namespaces? They will try to work around<br>
&gt; them.</div></blockquote><div><br>The proposal really does not erect any kind of fences. It establishes some core extensions for use only inside of a specific file. Nothing stops users from reopening the namespaces (in the proposal, they are simple modules) and modifying the methods. Likewise, nothing stops users from using the namespaces in their own code. There is nothing in the proposal designed to block users from doing what they want.<br>
/div><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">&gt; Engineering software by trying to protect against the invisible,<br>

&gt; unknowable, purely speculative demons that lurk in some future world<br>
&gt; leads to horrible languages and even worse software. One of the things<br>
&gt; Ruby has going for it is some very good software that judiciously<br>
&gt; changes assumptions made at the time other software/code was written.</div></blockquote><div><br>The proposal is based on real-life problems faced by real-life users using real-life frameworks. I captured the use-case inhe OP (Rails and Merb both defining String#camel_case), which has actually bitten real users trying to use Merb with ActiveRecord.<br>
/div><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"><br>
<br>
</div>I think the two paragraphs contrast a bit :)<br>
<br>
However, to offer an alternative consideration, how about a real<br>
mechanism for &quot;unrequiring&quot; and/or &quot;unextending&quot;? Particularly the<br>
non-methodwise variants of selector namespaces could very well be<br>
replaced by being able to (really) activate and deactivate files<br>
or modules at runtime.</blockquote><div><br>unrequiring is actually more complex of a feature to implement with no additional benefits that I can see.nextending doesn&#39;t solve the problem at all (except to provide a slownd extremely awkward way to emulate the feature on an object-by-object basis).<br>
br>The proposal is actually fairly straight-forward, relatively simple to implement, and does not introduce any &quot;barriers&quot; for users at all.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
--<br><div><div class="Wj3C7c">
Magic is insufficiently advanced technology.<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.1325<br>

--000e0cd2de44980fb80463b255f9--