From: Yehuda Katz Date: 2009-02-20T04:46:29+09:00 Subject: [ruby-core:22267] Re: YASNP (Yet Another Selector Namespace Proposal) --001636e0a64a68cb3a04634ac638 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/2/19 Florian Gilcher > > On Feb 19, 2009, at 8:15 AM, Charles Oliver Nutter wrote: > > Charles Oliver Nutter wrote: >> >>> Caveats: >>> * HACKHACKHACK >>> * Only works for single-arg "call" in this case, but easy to generalize >>> to all other calls >>> * The namespace never gets turned off in this example. It wouldn't be >>> hard to add with parser help, but there's no trigger I can use in this >>> simple version. >>> * Interpreter-only. Compilation would be a bit trickier, but not much. >>> >> >> Another important one: >> >> * This version searches the namespace for the method *unconditionally*. It >> would probably be desirable to identify whether it applies to the receiver >> or not: >> >> use String => Merb::String >> >> And then the namespace association only applies when the receiver is_a? >> String. >> >> - Charlie >> >> > > That sounds a lot like the Objective-C method poseAs, discarding some of > it's limitations. > > But what is the scope of use? AFAIK, there is no construct in Ruby that has > a file-only scope (except the ones that need to be closed because of > syntactical reasons). Granted, those are details. I would be open to making it take a block, but I'm not aware of any use-case where that would be helpful, so I left it out at the beginning to reduce the need for extra ceremony. > > > But what about this example in Yehudas gist: > > === > # require "my_app3", :use => Merb::String > > "hello_goodbye".camel_case #=> "HelloGoodbye" > "hello_goodbye".camel_case(true) #=> ArgumentError > === > > Making it externally controllable which class a file uses is at least > discussable. I don't like it, especially because it is not really fitting in > Rubys way of not seeing files as program units. Again, I'm open to doing it a different way. I chose this initially because it makes it easier to implement at parse-time (which is required for performance) and because I can't think of any use-case where more granular application of namespaces would actually be useful, but I'd be fine with "use" taking a block if it moved the proposal forward. > 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. > > > Regards, > Florian Gilcher > > -- > Florian Gilcher > > smtp: flo@andersground.net > jabber: Skade@jabber.ccc.de > gpg: 533148E2 > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --001636e0a64a68cb3a04634ac638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/2/19 Florian Gilcher <flo@andersground.net>= ;

On Feb 19, 2009, at 8:15 AM, Charles Oliver Nutter wrote:

Charles Oliver Nutter wrote:

Caveats:
* HACKHACKHACK
* Only works for single-arg "call" in this case, but easy to gene= ralize to all other calls
* The namespace never gets turned off in this example. It wouldn't be h= ard to add with parser help, but there's no trigger I can use in this s= imple version.
* Interpreter-only. Compilation would be a bit trickier, but not much.

Another important one:

* This version searches the namespace for the method *unconditionally*. It = would probably be desirable to identify whether it applies to the receiver = or not:

use String =3D> Merb::String

And then the namespace association only applies when the receiver is_a? Str= ing.

- Charlie

That sounds a lot like the Objective-C method poseAs, discarding some of it= 's limitations.

But what is the scope of use? AFAIK, there is no construct in Ruby that has= a file-only scope (except the ones that need to be closed because of synta= ctical reasons). Granted, those are details.

I would b= e open to making it take a block, but I'm not aware of any use-case whe= re that would be helpful, so I left it out at the beginning to reduce the n= eed for extra ceremony.

But what about this example in Yehudas gist:

=3D=3D=3D
# require "my_app3", :use =3D> Merb::String

"hello_goodbye".camel_case #=3D> "HelloGoodbye"
<= /div> "hello_goodbye".camel_case(true) #=3D> ArgumentError
=3D=3D=3D

Making it externally controllable which class a file uses is at least discu= ssable. I don't like it, especially because it is not really fitting in= Rubys way of not seeing files as program units.

Again, I'm open to doing it a different way. I chose this initially bec= ause it makes it easier to implement at parse-time (which is required for p= erformance) and because I can't think of any use-case where more granul= ar application of namespaces would actually be useful, but I'd be fine = with "use" taking a block if it moved the proposal forward.

Also,= only one parametrization can be in place at once, which smells like a sour= ce of conflicts.

"only one parametrization can be in place at once" -- I = don't understand what you mean by this.

Regards,
Florian Gilcher

--
Florian Gilcher

smtp: flo@= andersground.net
jabber: Skade@jabb= er.ccc.de
gpg: 533148E2

--
Yehuda Katz
D= eveloper | Engine Yard
(ph) 718.877.1325
--001636e0a64a68cb3a04634ac638--