From: Yehuda Katz Date: 2009-02-26T04:09:51+09:00 Subject: [ruby-core:22491] Re: YASNP (Yet Another Selector Namespace Proposal) --000e0cd32746f94afb0463c2fcdd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/2/25 Florian Gilcher > > 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: flo@andersground.net > jabber: Skade@jabber.ccc.de > gpg: 533148E2 > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --000e0cd32746f94afb0463c2fcdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

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.

=A0
The problem is rather obvious: suddently, I can have m= ultiple 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 ab= out the same everywhere (safe for the unusual catch that it could be un/red= efined along the way). With selector namespaces, that catch would get commo= nplace.=A0

Not really... because the namespaces would nee= d 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 explicitl= y invoked. It's also not the case that when *I* invoke a selector names= pace 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 Contex= t C, because you have a breakpoint there. You have an assertion about a pro= perty of the object that you will use later on. You want to check that asse= rtion _now_. But as "later on" happens to be in Context D, you as= sertion 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 th= at already exist in Ruby, but in a targeted, explicit scope. I don't se= e how this introduces vast NEW confusion.
=A0
I don't want to present this as a showstop= per. But it _is_ something that can happen which couldn't happen before= . It will certainly not happen to us good programmers.

=A0
I don't see it as something overly complex. But= then again I also see this with the mind of my collegues that really strug= gle even with the concept of :method_missing. So I try to illustrate both s= ides. I like to adopt both viewpoints for the sake of an internal discussio= n.

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

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

I'd assume that namespaces would apply to = the rest of the IRB session. Perhaps a "using nil" could be speci= fied to deactivate namespaces.

Hm, i would prefer to ac= tually being able to switch. Especially, because i use irb heavily for deve= lopment of new code, not just to check.

=A0
In favor of the proposal, I a= lso want to construct explain a case where I always missed it. Take ActiveR= ecord or DataMapper. The objects usually get passed into a template (a comp= letely 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 ki= nds 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: le= t the view be a evaluted in a different Namespace. This would also allow fo= r "convenience methods" to be added in the view exclusively.

It wouldn't really work that way, unless y= ou explicitly removed methods from the global ActiveRecord and only made th= em available in a specific namespace. Even then, it would be trivial to inc= lude the namespace in question into the templates.

Oh, sure, nothing is foo= lproof. But it shows an intention.[1] I also just wanted to construct a cas= e i see coming for DataMapper and ActiveRecord, but some future library mig= ht make use of semantics like that. And it is a case most people handle eve= ry day.

Sure.
=A0


[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 vibran= t 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 l= anguage; instead, it aims to be NATURAL.
=A0=A0

I never got that NATURA= L. 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 nat= ure of the context.
I like Ruby for keeping a complex thing complex. Perhaps thats natural= , perhaps not.

Hehe ;)
=A0

Regards,
Florian

[1]: I like code hinting at the intention of a= programmer. It gives you the possibility not to support people that work a= gainst 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 us= e __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.


--
Flor= ian Gilcher

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



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