From: Yehuda Katz Date: 2009-02-26T01:31:31+09:00 Subject: [ruby-core:22469] Re: YASNP (Yet Another Selector Namespace Proposal) --000e0cd2e61c617ed10463c0c723 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/2/25 Florian Gilcher > > On Feb 25, 2009, at 6:17 AM, Yehuda Katz wrote: > > I'm also in favor of discussing this, but all I hear so far in opposition > is vague FUD... no specific examples of problems that could be caused. It > would be a lot easier to have a lively discussion about specific concerns, > and I'd love to have it! > -- Yehuda > > > Is FUD the new "the opposition doesn't convince me"? I hear it a lot. I > think it's overused. Also, I find it insulting or at least a "verbal" > fauxpas as well as misplaced[1]. > Apologies. > The problem is rather obvious: suddently, I can have multiple definitions > of a method (or none!) depending on context. Nowadays, i can just > inspect/test that behaviour in IRB/rdb and be sure that it is about the same > everywhere (safe for the unusual catch that it could be un/redefined along > the way). With selector namespaces, that catch would get commonplace. > Not really... because the namespaces would need to be specified on a per-file basis (as per Matz), it would be trivial to go into a file and determine which namespaces were in use. Remember, this is not a global facility, it's per-file facility that must be explicitly invoked. It's also not the case that when *I* invoke a selector namespace in my library code, it effects your library code or your app. > This could be fixed by additional inspection facilities, but it _is_ an > additional layer of complexity (and not a small one). I also don't buy the > "no one will use it" argument. Back when I started learning Ruby, I heard > the same about redefining/extending core methods/objects. Nowadays, you > cannot find a lib that doesn't have it's small extension to Object. > It's not really relevant if people will use it, because it must be explicitly invoked. In other words, someone else can't invoke a selector namespace on your code. I think the most common use-case will likely be frameworks and libraries, but if you want to extend string for the duration of your application, and explicitly include the namespace into your files, that doesn't bother me. In short, it doesn't seem as complex as people are making it out to seem, or even more complex than facilities we have in Ruby today. > BTW: how will IRB handle file-based switches? > I'd assume that namespaces would apply to the rest of the IRB session. Perhaps a "using nil" could be specified to deactivate namespaces. > In favor of the proposal, I also want to construct explain a case where I > always missed it. Take ActiveRecord or DataMapper. The objects usually get > passed into a template (a completely different context) where most of the > methods are not intended to be used (#find being the common case, basically > everything that does Database operations explicitly). The uninitiated (TM) > still use them, causing all kinds of problems to the initiated (TM). > > Some frameworks I know (mostly PHP) solve this problem by hydrating the > database objects to an array before handing them over to the view. With > selector namespaces, there would be an easy fix for this: let the view be a > evaluted in a different Namespace. This would also allow for "convenience > methods" to be added in the view exclusively. > It wouldn't really work that way, unless you explicitly removed methods from the global ActiveRecord and only made them available in a specific namespace. Even then, it would be trivial to include the namespace in question into the templates. > Regards, > Florian > > [1]: FUD stands for a marketing strategy after all. There is no market at > ruby-core. And we are not corporate goons trying to keep you from something. > Hehe... Perhaps a strong term. I was trying to get across that the objections were vague, and in the interest of a vibrant discussion, I was hoping for some clear examples that would be so complex as to justify the derision. After all, Ruby is not a particularly simple language; instead, it aims to be NATURAL. > > -- > Florian Gilcher > > smtp: flo@andersground.net > jabber: Skade@jabber.ccc.de > gpg: 533148E2 > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --000e0cd2e61c617ed10463c0c723 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

On Feb 25, 2009, at 6:1= 7 AM, Yehuda Katz wrote:

I'm also in= favor of discussing this, but all I hear so far in opposition is vague FUD= ... no specific examples of problems that could be caused. It would be a lo= t easier to have a lively discussion about specific concerns, and I'd l= ove to have it!

-- Yehuda

Is FUD the= new "the opposition doesn't convince me"? I hear it a lot. I= think it's overused. Also, I find it insulting or at least a "ver= bal" fauxpas as well as misplaced[1].

Apologies.
=A0
The probl= em is rather obvious: suddently, I can have multiple definitions of a metho= d (or none!) depending on context. Nowadays, i can just inspect/test that b= ehaviour in IRB/rdb and be sure that it is about the same everywhere (safe = for the unusual catch that it could be un/redefined along the way). With se= lector namespaces, that catch would get commonplace.=A0

Not really... because the namespaces would need= to be specified on a per-file basis (as per Matz), it would be trivial to = go into a file and determine which namespaces were in use. Remember, this i= s not a global facility, it's per-file facility that must be explicitly= invoked. It's also not the case that when *I* invoke a selector namesp= ace in my library code, it effects your library code or your app.
=A0
This could be fixed by additional inspection facili= ties, but it _is_ an additional layer of complexity (and not a small one). = I also don't buy the "no one will use it" argument. Back when= I started learning Ruby, I heard the same about redefining/extending core = methods/objects. Nowadays, you cannot find a lib that doesn't have it&#= 39;s small extension to Object.

It's not really relevant if people will use= it, because it must be explicitly invoked. In other words, someone else ca= n't invoke a selector namespace on your code. I think the most common u= se-case will likely be frameworks and libraries, but if you want to extend = string for the duration of your application, and explicitly include the nam= espace into your files, that doesn't bother me. In short, it doesn'= t seem as complex as people are making it out to seem, or even more complex= than facilities we have in Ruby today.
=A0
BTW: how will IRB handle file-based switches?=A0

I'd assume that namespaces would apply to the res= t of the IRB session. Perhaps a "using nil" could be specified to= deactivate namespaces.
=A0
In favor of the proposal, I also want to co= nstruct explain a case where I always missed it. Take ActiveRecord or DataM= apper. The objects usually get passed into a template (a completely differe= nt context) where most of the methods are not intended to be used (#find be= ing the common case, basically everything that does Database operations exp= licitly). The uninitiated (TM) still use them, causing all kinds of problem= s to the initiated (TM).

Some frameworks I know (mostly PHP) solve this problem = by hydrating the database objects to an array before handing them over to t= he view. With selector namespaces, there would be an easy fix for this: let= the view be a evaluted in a different Namespace. This would also allow for= "convenience methods" to be added in the view exclusively.

It wouldn't really work that way, unless yo= u explicitly removed methods from the global ActiveRecord and only made the= m available in a specific namespace. Even then, it would be trivial to incl= ude the namespace in question into the templates.
=A0
Regards,
Florian

[1]: FUD stands for=A0a marketing strategy after all. There is no market a= t ruby-core. And we are not corporate goons trying to keep you from somethi= ng.

Hehe... Perhaps a strong term. I was trying to = get across that the objections were vague, and in the interest of a vibrant= discussion, I was hoping for some clear examples that would be so complex = as to justify the derision. After all, Ruby is not a particularly simple la= nguage; instead, it aims to be NATURAL.
=A0
=A0
--
Flor= ian Gilcher

jabber: Skade@jabber.ccc.de<= /a>
gpg: =A0 =A0533148E2
=



--
Yehuda = Katz
Developer | Engine Yard
(ph) 718.877.1325
--000e0cd2e61c617ed10463c0c723--