From: Florian Gilcher Date: 2009-02-25T17:47:27+09:00 Subject: [ruby-core:22460] Re: YASNP (Yet Another Selector Namespace Proposal) --Apple-Mail-47--453551303 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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]. 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. 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. BTW: how will IRB handle file-based switches? 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. 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. -- Florian Gilcher smtp: flo@andersground.net jabber: Skade@jabber.ccc.de gpg: 533148E2 --Apple-Mail-47--453551303 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
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].

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. 
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.

BTW: how will IRB handle file-based = switches? 

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.

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.
 
--
Florian = Gilcher

gpg:=    533148E2
 =

= --Apple-Mail-47--453551303--