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

2009/2/25 Florian Gilcher <[e-mail]>

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

That can already happen if the framework does A.extend(Something). That's
what I don't get about all of this. Ruby is already a very flexible language
that allows fairly crazy things to happen to objects and the global space.
This allows the same features that already exist in Ruby, but in a targeted,
explicit scope. I don't see how this introduces vast NEW confusion.


> 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 was just trying to say that I anticipated the main use of this to be in
frameworks. I have no problem with advanced users using it in their apps,
and in the same way that instance/class_eval isn't common in Rails apps (but
is very common in Rails itself), I would expect selector namespaces to be
common in frameworks and less common in applications.


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

I don't see it as any more complex than method_missing. It is perhaps
simpler, since you need to include the namespace in the same file that it is
used.


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

Sure.


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

Hehe ;)


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


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325