From: Florian Gilcher Date: 2009-02-26T03:51:10+09:00 Subject: [ruby-core:22485] Re: YASNP (Yet Another Selector Namespace Proposal) --Apple-Mail-90--417394233 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > 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: flo@andersground.net jabber: Skade@jabber.ccc.de gpg: 533148E2 --Apple-Mail-90--417394233 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

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

gpg:=    533148E2
 =

= --Apple-Mail-90--417394233--