--000e0cd32746f94afb0463c2fcdd
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

<br><br><div class="gmail_quote">2009/2/25 Florian Gilcher <span dir="ltr">&lt;flo / andersground.net&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><div class="Ih2E3d"><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div>Is FUD the new &quot;the opposition doesn&#39;t convince me&quot;? I hear it a lot. I think it&#39;s overused. Also, I find it insulting or at least a &quot;verbal&quot; fauxpas as well as misplaced[1].</div> </div>
</blockquote><div><br>Apologies.<br></div></div></blockquote><div><br></div></div>Accepted, no hard feelings.</div><div><div class="Ih2E3d"><br><blockquote type="cite"><div class="gmail_quote"><div>/div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div>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./div>
 </div></blockquote><div><br>Not really... because the namespaces would need to be specified on a per-file basis (as per Matz), it would be trivial too into a file and determine which namespaces were in use. Remember, this is not a global facility, it&#39;s per-file facility that must be explicitly invoked. It&#39;s also not the case that when *I* invoke a selector namespace in my library code, it effects your library code or your app. <br>
</div></div></blockquote><div><br></div></div><div>Yes. I&#39;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 &quot;later on&quot; happens to be in Context D, you assertion is true now but wrong later on.</div>
</div></div></blockquote><div><br>That can already happen if the framework does A.extend(Something). That&#39;s what I don&#39;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&#39;t see how this introduces vast NEW confusion.<br>
/div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div></div><div>I don&#39;t want to present this as a showstopper. But it _is_ something that can happen which couldn&#39;t happen before. It will certainly not happen to us good programmers.</div>
<div class="Ih2E3d"><br><blockquote type="cite"><div class="gmail_quote"><div> /div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div>
</div><div>This could be fixed by additional inspection facilities, but it _is_ an additional layer of complexity (and not a small one). I also don&#39;t buy the &quot;no one will use it&quot; 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&#39;t have it&#39;s small extension to Object.</div>
 </div></blockquote><div><br>It&#39;s not really relevant if people will use it, because it must be explicitly invoked. In other words, someone else can&#39;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 extendtring for the duration of your application, and explicitly include the namespace into your files, that doesn&#39;t bother me. In short, it doesn&#39;t seem as complex as people are making it out to seem, or even more complex than facilities we have in Ruby today. <br>
</div></div></blockquote><div><br></div></div>Sure, but one of your arguments was that it won&#39;t be widly used anyways ;).</div></div></blockquote><div><br>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 theirpps, and in the same way that instance/class_eval isn&#39;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.<br>
/div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div>I don&#39;t see it as something overly complex. Buthen 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.</div>
</div></blockquote><div><br>I don&#39;t see it as any more complex than method_missing. It is perhaps simpler, since you need to include the namespacen the same file that it is used.<br>br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div></div><div><br></div><div><div class="Ih2E3d"><blockquote type="cite"><div class="gmail_quote"><div> /div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div>BTW: how will IRB handle file-based switches?/div></div> </blockquote><div><br>I&#39;d assume that namespaces would apply to the rest of the IRB session. Perhaps a &quot;using nil&quot; could be specified to deactivate namespaces.<br>
</div></div></blockquote><div><br></div></div><div>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.</div><div class="Ih2E3d"><br><blockquote type="cite">
<div class="gmail_quote"><div>/div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div>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).</div>
 <div><br></div><div>Some frameworks I know (mostly PHP) solve this problemy 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 &quot;convenience methods&quot; to be added in the view exclusively.</div>
 </div></blockquote><div><br>It wouldn&#39;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.<br>
</div></div></blockquote><div><br></div></div><div>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.</div>
</div></div></blockquote><div><br>Sure.<br>/div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div></div><div class="Ih2E3d">
<div><br></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div><br></div><div>[1]: FUD stands for              箼
 </div></blockquote><div><br>Hehe... Perhaps a strong term. I was trying toet 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 complexs to justify the derision. After all, Ruby is not a particularly simple language; instead, it aims to be NATURAL.<br>
  </div></div></blockquote><br></div></div><div>I never got that NATURAL. ATM, I work at a company where everything outside of Java, RFC calls andML is unnatural. For those people, Java is natural. Because thats the nature of the context.</div>
<div>I like Ruby for keeping a complex thing complex. Perhaps thats natural, perhaps not.</div></div></blockquote><div><br>Hehe ;)<br>/div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div></div><div><br></div><div>Regards,</div><div>Florian</div><div><div><br></div><div>[1]: I like code hinting at the intention of arogrammer. It gives you the possibility not to support people that work against your intentions. &quot;But I was able to make it available&quot; is far less of an argument then &quot;I was able to make it available&quot;.</div>
<div>The same argument goes for private methods. &quot;But I was able to use __send__ to call it in the last version&quot; is different from &quot;Butas able to call it&quot;. I don&#39;t give out support for people usingy private methods while I do invite them to do whatever they want with itf they know what they are doing.</div>
<div><br></div></div><div class="Ih2E3d"><div><br></div><div> <span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div style="">
<div><div style=""><div style=""><div style=""><div>--</div><div>Florian Gilcher</div><div><br></div><div>smtp: <a href="mailto:flo / andersground.net" target="_blank">flo / andersground.net</a></div><div>jabber: <aref="mailto:Skade / jabber.ccc.de" target="_blank">Skade / jabber.ccc.de</a></div>
<div>gpg: 33148E2</div></div></div></div></div></div></span> </div><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.1325<br>

--000e0cd32746f94afb0463c2fcdd--