From: Yehuda Katz Date: 2009-02-21T01:39:53+09:00 Subject: [ruby-core:22295] Re: YASNP (Yet Another Selector Namespace Proposal) --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 > > 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 Barnet= te, a somewhat modified proposal:

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

Main changes:
Take a look at the gist for more details. I think this is a significan= tly refined proposal than the one I submitted a few days ago.

-- Yeh= uda

2009/2/20 Florian Gilcher <flo@andersground.net>
<= br>
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 sou= rce 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 v= ocabulary. I wanted to say that by suddently making require passing in para= meters into the code loading process, you open the door for problems such a= s this:

Lib A loads some file with:

re= quire 'foolib', use String =3D> LibA::String

Another one does:

require 'foolib', = use String =3D> LibB::String

Which String class does foolib use now? The first, the = last, undefined? Based on the behaviour of require: the first one, which wo= uld 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 mak= ing it so easy to produce a clash seems a bit careless.

Just for the record: I would really like to see some kind of namespac= ing/posing in Ruby. But the topic is a dangerous one, a careless approach c= ould 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 ha= rdcore programmer, but not a language designer.

Re= gards,
Florian

[1]: in memory of the "\" o= perator ;).
[2]: that could be an interesting thesis topic.
=





--
Y= ehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
--000e0cd32d06a62ea404635c4e71--