[ruby-core:22485] Re: YASNP (Yet Another Selector Namespace Proposal)

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

Accepted, no hard feelings.

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

Yes. I'm more about reconstruction what happens later on. Say... you  
have an Object A in Context C, because you have a breakpoint there.  
You have an assertion about a property of the object that you will use  
later on. You want to check that assertion _now_. But as "later on"  
happens to be in Context D, you assertion is true now but wrong later  
on.

I don't want to present this as a showstopper. But it _is_ something  
that can happen which couldn't happen before. It will certainly not  
happen to us good programmers.

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

Sure, but one of your arguments was that it won't be widly used  
anyways ;).

I don't see it as something overly complex. But then again I also see  
this with the mind of my collegues that really struggle even with the  
concept of :method_missing. So I try to illustrate both sides. I like  
to adopt both viewpoints for the sake of an internal discussion.

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

Hm, i would prefer to actually being able to switch. Especially,  
because i use irb heavily for development of new code, not just to  
check.

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

Oh, sure, nothing is foolproof. But it shows an intention.[1] I also  
just wanted to construct a case i see coming for DataMapper and  
ActiveRecord, but some future library might make use of semantics like  
that. And it is a case most people handle every day.

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

I never got that NATURAL. ATM, I work at a company where everything  
outside of Java, RFC calls and XML is unnatural. For those people,  
Java is natural. Because thats the nature of the context.
I like Ruby for keeping a complex thing complex. Perhaps thats  
natural, perhaps not.

Regards,
Florian

[1]: I like code hinting at the intention of a programmer. It gives  
you the possibility not to support people that work against your  
intentions. "But I was able to make it available" is far less of an  
argument then "I was able to make it available".
The same argument goes for private methods. "But I was able to use  
__send__ to call it in the last version" is different from "But i was  
able to call it". I don't give out support for people using my private  
methods while I do invite them to do whatever they want with it if  
they know what they are doing.


--
Florian Gilcher

smtp:   [e-mail]
jabber: [e-mail]
gpg:    533148E2