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

Ok, based on a bunch of comments I got from Aaron Patterson and John
Barnette, a somewhat modified proposal:

https://gist.github.com/83d390aea81a12f1667c

Main changes:

   - "use" is scoped
   - no special namespace keyword; any module can be a namespace
   - use Merb::String for String
   - use Merb::* (equivalent to Merb.constants.each {|k| use k for
   k.split("::", 2).last.constantize })

Take a look at the gist for more details. I think this is a significantly
refined proposal than the one I submitted a few days ago.

-- Yehuda

2009/2/20 Florian Gilcher <flo / andersground.net>

>
> On Feb 19, 2009, at 8:46 PM, Yehuda Katz wrote:
>
>
> Also, only one parametrization can be in place at once, which smells like a
>> source of conflicts.
>
>
> "only one parametrization can be in place at once" -- I don't understand
> what you mean by this.
>
>
>
> I don't know whether I picked the right vocabulary. I wanted to say that by
> suddently making require passing in parameters into the code loading
> process, you open the door for problems such as this:
>
> Lib A loads some file with:
>
> require 'foolib', use String LibA::String
>
> Another one does:
>
> require 'foolib', use String LibB::String
>
> Which String class does foolib use now? The first, the last, undefined?
> Based on the behaviour of require: the first one, which would make LibB
> fail. Granted, you could find ways around this, but not that simple ones.[2]
> Granted, we already have that problem with redefining methods, but making
> it so easy to produce a clash seems a bit careless.
>
> Just for the record: I would really like to see some kind of
> namespacing/posing in Ruby. But the topic is a dangerous one, a careless
> approach could break the language[1].
> I believe it would also require to fundamentally rethink the way ruby
> packages code.
>
> But then again, I may be a hardcore programmer, but not a language
> designer.
>
> Regards,
> Florian
>
> [1]: in memory of the "\" operator ;).
> [2]: that could be an interesting thesis topic.
>
> --
> Florian Gilcher
>
> smtp:   flo / andersground.net
> jabber: Skade / jabber.ccc.de
> gpg:    533148E2
>
>


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

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

Ok, based on a bunch of comments I got from Aaron Patterson and John Barnette, a somewhat modified proposal:<br><br>https://gist.github.com/83d390aea81a12f1667c<br>
<br>Main changes:<br><ul><li>&quot;use&quot; is scoped</li><li>no special namespace keyword; any module can be a namespace</li><li>use Merb::String for String</li><li>use Merb::* (equivalent to Merb.constants.each {|k| use k for k.split(&quot;::&quot;, 2).last.constantize })</li>
</ul>Take a look at the gist for more details. I think this is a significantly refined proposal than the one I submitted a few days ago.<br><br>-- Yehuda<br><br><div class="gmail_quote">2009/2/20 Florian Gilcher <span dir="ltr">&lt;flo / andersground.net&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 style=""><br><div><div class="Ih2E3d"><div>On Feb 19, 2009, at 8:46 PM, Yehuda Katzrote:</div>
<blockquote type="cite"><div class="gmail_quote"><font color="#000000"><br></font><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, only one parametrization can be in place at once, which smells like a source of conflicts.</blockquote>
 <div><br>&quot;only one parametrization can be in place at once&quot; -- Ion&#39;t understand what you mean by this.<br>&nbsp;</div></div></blockquote><div><br></div></div><div>I don&#39;t know whether I picked the right vocabulary. I wanted to say that by suddently making require passing in parameters into the code loading process, you open the door for problems such as this:</div>
<div><br></div><div>Lib A loads some file with:</div><div><br></div><div>require &#39;foolib&#39;, use String =&gt; LibA::String</div><div><br></div><div>Another one does:</div><div><br></div><div>require &#39;foolib&#39;, use String =&gt; LibB::String</div>
<div><br></div><div>Which String class does foolib use now? The first, the last, undefined? Based on the behaviour of require: the first one, which would make LibB fail. Granted, you could find ways around this, but not that simple ones.[2]</div>
<div>Granted, we already have that problem with redefining methods, but making it so easy to produce a clash seems a bit careless.</div><div><br></div><div>Just for the record: I would really like to see some kind of namespacing/posing in Ruby. But the topic is a dangerous one, a careless approach could break the language[1].</div>
<div>I believe it would also require to fundamentally rethink the way ruby packages code.&nbsp;</div><div><br></div><div>But then again, I may be a hardcore programmer, but not a language designer.</div><div><br></div><div>Regards,</div>
<div>Florian</div><div><br></div><div>[1]: in memory of the &quot;\&quot; operator ;).</div><div>[2]: that could be an interesting thesis topic.</div><div><br></div></div><div class="Ih2E3d"><div> <span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div style="">
<div><div style=""><div style=""><div style=""><div>--</div><div>Florian Gilcher</div><div><br></div><div>smtp: &nbsp; <a href="mailto:flo / andersground.net" target="_blank">flo / andersground.net</a></div><div>jabber:a href="mailto:Skade / jabber.ccc.de" target="_blank">Skade / jabber.ccc.de</a></div>
<div>gpg: &nbsp; &nbsp;533148E2</div></div></div></div></div></div></span> </div><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.1325<br>

--000e0cd32d06a62ea404635c4e71--