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

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