Little Things

Discussion in 'Ruby' started by Trans, Dec 30, 2006.

  1. Trans

    Trans Guest

    I was a bit surprised about Matz mention of the little things in his
    last <a
    href="http://www.rubyist.net/~matz/slides/rc2006/mgp00017.html">ketynote</a>.
    Little things can make all the difference! In fact, long time Rubyists
    have been waiting a long for some important "little" things. Here's
    some of the things on my little list....

    * Binding.of_caller. Yes, it's easy to abuse, and should be avoided at
    nearly all costs. But there are few pennies worth when nothing else
    will do. Some very cool metatricks are made possible by being able to
    access the caller's binding --the breakpoint lib being the most well
    known.

    * <code>object_class</code> instead of </code>class</code>. I get sick
    just looking at <code>self.class.foo</code>. And it prevents use of
    "class" for other variables/methods. (Hence the all too frequent use of
    "klass"). <code>object_class</code> on the other hand is nicely
    analogous to <code>object_id</code>.

    * Allow a comma between the two <code>alias</code> arguments --getting
    an error on that is really annoying. Actually why is <code>alias</code>
    a keyword? Why have both <code>#alias_method</code> and
    <code>alias</code>? I have always been told that keywords were to be
    avoided.

    * <code>String#resc</code> as an inversion of
    <code>Regexp.escape(string)</code> and <code>String#to_re</code> as an
    inversion of <code>Regexp.new(string)</code>.

    * I'm dying here from remove_method hacks without
    <code>#instance_exec</code>. This has to rank in the top three "little
    things" that have been talked about forever, and it isn't that hard to
    implement. So what's holding it up?

    * A block can't take a block, nor default arguments. What kind of
    <code>define_method</code> is this? I realize this a trickier issue.
    But at some point the trick has to be performed.

    * Close the closures. Writing DSLs is great, but have you noticed they
    all share the same closure? Have a way to reset the closure with some
    sort of special block notation would shore-up this danger hole. Maybe:

    <pre>
    a = 1
    dosomething do! |x|
    p a #=> error
    end
    </pre>

    * Another hassle when metaprogramming. <code>#send</code> should work
    for public methods only! There's a big issue with backward
    compatibility here. I have the solution: <code>#object_send</code>.
    It's a better name anyway b/c it stays out of the way (eg. my Email
    module would like to have a #send method, you dig?). And #send itself
    could be deprecated slowly. BTW <code>#funcall</code> for the alternate
    private-accessing send is a <b>terrible</b> name, try
    <code>#instance_send</code>. (And yes, I'm begging here!)

    * This one's more of my own pet-peeve but nontheless, who wouldn't want
    a nice word alias for Class#===. In most cases I prefer to read what
    I'm doing rather then recall the interpretation of a symbol. There are
    of course some symbols that are rather obvious, either by indication of
    their form (eg. <<) or by their widespread use (eg. =), but Class#===
    is not one of them. I would much prefer to see:

    <pre>
    MyClass.instance?(myobject)
    </pre>

    But I'm not picky about what word to use as long as it's readable.

    * Oh, and lets not forget the forever arguable method name for (class
    << self; self; end). But please give us something concise.

    No doubt there other little things left unmentioned, and obviously some
    are more important than others. But in any case, it's clearly striking
    that after hearing for so long about many such well-accepted "little
    things", that Ruby has yet to take them in. I have a silly theory about
    this actually --as odd as it may seem. The 1.9 version is the last on
    the chain before 2.0 b/c matz is against using double-digit minor
    numbers, eg 1.10. So we're is stuck with 1.9 as his test bed for 2.0.
    Since 1.8 can only increment by teeny, these "little things", being not
    little enough, can't make it in. Hence Ruby is being held back by a
    version number policy!!! I think Matz just needs to get on with it (hey
    look forward to 3.0!) or just lossen the version policy constraints.

    T.

    PS. [And, yes, I took my own advice. I removed this from my blog --"it
    is better to share than to own".]
     
    Trans, Dec 30, 2006
    #1
    1. Advertising

  2. Trans

    matt Guest

    Thanks for bringing these slides to my attention. This one caught my
    eye:
    http://www.rubyist.net/~matz/slides/rc2006/mgp00027.html

    "We need to Document Ruby (if Possible)." as part of the Design Game of
    improving Ruby.

    That kind of a statement is what could potentially kill the language.
    We can have the best language on the Planet, but if the language
    features are only accessible to those that are willing to go code-diving
    for the answers, then the target audience is going to be slim.

    The truth is that there are a lot of well intentioned programmers out
    there, but they don't have the first clue (or inclination) to go digging
    deep into the bowels of Ruby (or any language).

    That is why some of the less elegant languages have succeeded, and have
    such a large following. It is (in large part) because of there
    documentation. It is up-to-date, adequate, easy to search, and
    well-defined.

    I don't pretend that all share my view on documentation, but for the
    Ruby leader/CEO to put documentation so far down on the list I think is
    going to make it difficult for language to grab ahold of programming
    share the way that Perl, Python and PHP have.

    my .02

    Matt






    On Sun, 2006-12-31 at 02:27 +0900, Trans wrote:
    > I was a bit surprised about Matz mention of the little things in his
    > last <a
    > href="http://www.rubyist.net/~matz/slides/rc2006/mgp00017.html">ketynote</a>.
    > Little things can make all the difference! In fact, long time Rubyists
    > have been waiting a long for some important "little" things. Here's
    > some of the things on my little list....
    >
    > * Binding.of_caller. Yes, it's easy to abuse, and should be avoided at
    > nearly all costs. But there are few pennies worth when nothing else
    > will do. Some very cool metatricks are made possible by being able to
    > access the caller's binding --the breakpoint lib being the most well
    > known.
    >
    > * <code>object_class</code> instead of </code>class</code>. I get sick
    > just looking at <code>self.class.foo</code>. And it prevents use of
    > "class" for other variables/methods. (Hence the all too frequent use of
    > "klass"). <code>object_class</code> on the other hand is nicely
    > analogous to <code>object_id</code>.
    >
    > * Allow a comma between the two <code>alias</code> arguments --getting
    > an error on that is really annoying. Actually why is <code>alias</code>
    > a keyword? Why have both <code>#alias_method</code> and
    > <code>alias</code>? I have always been told that keywords were to be
    > avoided.
    >
    > * <code>String#resc</code> as an inversion of
    > <code>Regexp.escape(string)</code> and <code>String#to_re</code> as an
    > inversion of <code>Regexp.new(string)</code>.
    >
    > * I'm dying here from remove_method hacks without
    > <code>#instance_exec</code>. This has to rank in the top three "little
    > things" that have been talked about forever, and it isn't that hard to
    > implement. So what's holding it up?
    >
    > * A block can't take a block, nor default arguments. What kind of
    > <code>define_method</code> is this? I realize this a trickier issue.
    > But at some point the trick has to be performed.
    >
    > * Close the closures. Writing DSLs is great, but have you noticed they
    > all share the same closure? Have a way to reset the closure with some
    > sort of special block notation would shore-up this danger hole. Maybe:
    >
    > <pre>
    > a = 1
    > dosomething do! |x|
    > p a #=> error
    > end
    > </pre>
    >
    > * Another hassle when metaprogramming. <code>#send</code> should work
    > for public methods only! There's a big issue with backward
    > compatibility here. I have the solution: <code>#object_send</code>.
    > It's a better name anyway b/c it stays out of the way (eg. my Email
    > module would like to have a #send method, you dig?). And #send itself
    > could be deprecated slowly. BTW <code>#funcall</code> for the alternate
    > private-accessing send is a <b>terrible</b> name, try
    > <code>#instance_send</code>. (And yes, I'm begging here!)
    >
    > * This one's more of my own pet-peeve but nontheless, who wouldn't want
    > a nice word alias for Class#===. In most cases I prefer to read what
    > I'm doing rather then recall the interpretation of a symbol. There are
    > of course some symbols that are rather obvious, either by indication of
    > their form (eg. <<) or by their widespread use (eg. =), but Class#===
    > is not one of them. I would much prefer to see:
    >
    > <pre>
    > MyClass.instance?(myobject)
    > </pre>
    >
    > But I'm not picky about what word to use as long as it's readable.
    >
    > * Oh, and lets not forget the forever arguable method name for (class
    > << self; self; end). But please give us something concise.
    >
    > No doubt there other little things left unmentioned, and obviously some
    > are more important than others. But in any case, it's clearly striking
    > that after hearing for so long about many such well-accepted "little
    > things", that Ruby has yet to take them in. I have a silly theory about
    > this actually --as odd as it may seem. The 1.9 version is the last on
    > the chain before 2.0 b/c matz is against using double-digit minor
    > numbers, eg 1.10. So we're is stuck with 1.9 as his test bed for 2.0.
    > Since 1.8 can only increment by teeny, these "little things", being not
    > little enough, can't make it in. Hence Ruby is being held back by a
    > version number policy!!! I think Matz just needs to get on with it (hey
    > look forward to 3.0!) or just lossen the version policy constraints.
    >
    > T.
    >
    > PS. [And, yes, I took my own advice. I removed this from my blog --"it
    > is better to share than to own".]
    >
    >
     
    matt, Dec 30, 2006
    #2
    1. Advertising

  3. Trans

    Trans Guest

    matt wrote:
    > Thanks for bringing these slides to my attention.


    Your welcome. I'm glad something good came from this post at least.

    Sorry about the html btw, should have removed that.

    > This one caught my
    > eye:
    > http://www.rubyist.net/~matz/slides/rc2006/mgp00027.html
    >
    > "We need to Document Ruby (if Possible)." as part of the Design Game of
    > improving Ruby.
    >
    > That kind of a statement is what could potentially kill the language.
    > We can have the best language on the Planet, but if the language
    > features are only accessible to those that are willing to go code-diving
    > for the answers, then the target audience is going to be slim.
    >
    > The truth is that there are a lot of well intentioned programmers out
    > there, but they don't have the first clue (or inclination) to go digging
    > deep into the bowels of Ruby (or any language).
    >
    > That is why some of the less elegant languages have succeeded, and have
    > such a large following. It is (in large part) because of there
    > documentation. It is up-to-date, adequate, easy to search, and
    > well-defined.
    >
    > I don't pretend that all share my view on documentation, but for the
    > Ruby leader/CEO to put documentation so far down on the list I think is
    > going to make it difficult for language to grab ahold of programming
    > share the way that Perl, Python and PHP have.


    Yea, I didn;t notice taht before. that is an odd statment to make. But
    I wouldn't put too much emphisis on it --sometimes people say things
    without meaning all the conotations tha can go with them.

    T.
     
    Trans, Dec 30, 2006
    #3
  4. Trans wrote:
    > This one caught my
    >> eye:
    >> http://www.rubyist.net/~matz/slides/rc2006/mgp00027.html
    >>
    >> "We need to Document Ruby (if Possible)." as part of the Design Game of
    >> improving Ruby.
    >>
    >> That kind of a statement is what could potentially kill the language.
    >> We can have the best language on the Planet, but if the language
    >> features are only accessible to those that are willing to go code-diving
    >> for the answers, then the target audience is going to be slim.
    >>
    >> The truth is that there are a lot of well intentioned programmers out
    >> there, but they don't have the first clue (or inclination) to go digging
    >> deep into the bowels of Ruby (or any language).
    >>
    >> That is why some of the less elegant languages have succeeded, and have
    >> such a large following. It is (in large part) because of there
    >> documentation. It is up-to-date, adequate, easy to search, and
    >> well-defined.
    >>
    >> I don't pretend that all share my view on documentation, but for the
    >> Ruby leader/CEO to put documentation so far down on the list I think is
    >> going to make it difficult for language to grab ahold of programming
    >> share the way that Perl, Python and PHP have.
    >>

    >
    > Yea, I didn;t notice taht before. that is an odd statment to make. But
    > I wouldn't put too much emphisis on it --sometimes people say things
    > without meaning all the conotations tha can go with them.

    Yes ... I was there, and in fact a group formed to do just that --
    document the syntax and semantics of Ruby 1.8. I know there's a web
    site, but I've forgotten where it is. Quite a few other "Ruby
    improvement" projects started up at RubyConf 2006, and for the most part
    they seem to be progressing nicely.

    However, regarding "programming share", or, as Eric Raymond says, "World
    Domination"
    (http://www.catb.org/~esr/writings/world-domination/world-domination-201.html),
    I don't think programming share is as simple as having better
    documentation than Perl, Python or PHP. Programming share comes from
    "industrial support", as demonstrated by Sun, IBM and Microsoft.

    Perl and Python, and even PHP, to some extent, are very much "rebel
    languages" alongside Java and C++. Should Ruby aim for programming share
    within the rebel languages group? Sure, why not? Yes, Ruby should be as
    well documented as the other three. But is achieving programming share
    relative to Java or C++ as an "industrial strength general purpose
    object oriented language" a realistic, achievable goal?

    --
    M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
    http://borasky-research.blogspot.com/

    If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
     
    M. Edward (Ed) Borasky, Dec 30, 2006
    #4
  5. I wonder if the reason a lot of these things don't happen is that matz
    doesn't really need them, and those that do, can't agree on a syntax (or
    elect a representative to make the decision for them). See below.

    Trans wrote:
    > * Binding.of_caller.

    I'd really prefer something more flexible, like what Mauricio did, or
    what Evan is doing with Rubinius.

    > * <code>object_class</code> instead of </code>class</code>.

    Interesting thought, but two things:
    - We could just fix it so you can say "class = ...". After all, local
    variable "foo" and method call "self.foo" can coexist.
    - It breaks the Huffman principle (for that matter, so does the current
    notation) that Tanaka Akira cited at RubyConf '04. We use self.class a
    heck of a lot more than object_id -- why should its name be longer?

    > * Allow a comma between the two <code>alias</code> arguments

    I think the reason both alias and alias_method exist is because the
    latter's supposed to be limited to dynamic situations. Akin to def vs
    define_method, undef vs undef_method, etc. That said, I'm ambivalent.

    > * A block can't take a block, nor default arguments. What kind of
    > <code>define_method</code> is this? I realize this a trickier issue.

    See 1.9.

    > * Close the closures.

    Interesting. Of course, the method author has the choice of calling
    instance_eval. And, well,

    def do!(&blk)
    obj = Object.new
    obj.define_method:)my_little_pony, &blk)
    obj.method:)my_little_pony) #.to_proc, if you prefer
    end

    a = 1
    dosomething &do! {|x|
    p a
    }

    > * Another hassle when metaprogramming. <code>#send</code> should work
    > for public methods only!

    See 1.9.

    > * This one's more of my own pet-peeve but nontheless, who wouldn't want
    > a nice word alias for Class#===.

    I'd like a nice word alias for Object#===. With Class#===, I prefer
    using is_a? class.

    Oh, and the spirit of Dave Thomas asks you to PDI.

    Devin
     
    Devin Mullins, Dec 30, 2006
    #5
  6. Duh... ignore this part. :p

    Devin Mullins wrote:
    > Trans wrote:
    >> * Close the closures.

    > Interesting. Of course, the method author has the choice of calling
    > instance_eval. And, well,
    >
    > def do!(&blk)
    > obj = Object.new
    > obj.define_method:)my_little_pony, &blk)
    > obj.method:)my_little_pony) #.to_proc, if you prefer
    > end
    >
    > a = 1
    > dosomething &do! {|x|
    > p a
    > }
     
    Devin Mullins, Dec 30, 2006
    #6
  7. Trans

    Trans Guest

    Devin Mullins wrote:
    > I wonder if the reason a lot of these things don't happen is that matz
    > doesn't really need them, and those that do, can't agree on a syntax (or
    > elect a representative to make the decision for them). See below.


    Well, it be nice to know what matz thought.

    > Trans wrote:
    > > * Binding.of_caller.

    > I'd really prefer something more flexible, like what Mauricio did, or
    > what Evan is doing with Rubinius.


    You mean a frame stack?

    > > * <code>object_class</code> instead of </code>class</code>.

    > Interesting thought, but two things:
    > - We could just fix it so you can say "class = ...". After all, local
    > variable "foo" and method call "self.foo" can coexist.


    Can it be done? Although, you loose access to the class in that case.
    I'd rather have both.

    > - It breaks the Huffman principle (for that matter, so does the current
    > notation) that Tanaka Akira cited at RubyConf '04. We use self.class a
    > heck of a lot more than object_id -- why should its name be longer?


    But at the same time promotes duck typing ;-)

    > > * Allow a comma between the two <code>alias</code> arguments

    > I think the reason both alias and alias_method exist is because the
    > latter's supposed to be limited to dynamic situations. Akin to def vs
    > define_method, undef vs undef_method, etc. That said, I'm ambivalent.


    > See 1.9.


    Sure I know. But that's like how many years away?

    > > * This one's more of my own pet-peeve but nontheless, who wouldn't want
    > > a nice word alias for Class#===.

    > I'd like a nice word alias for Object#===. With Class#===, I prefer
    > using is_a? class.


    However, it's safer to ask the class since the object can more readily
    "lie".

    > Oh, and the spirit of Dave Thomas asks you to PDI.


    That's almost funny :D

    Anyone else have any other common little things to add?

    T.
     
    Trans, Dec 30, 2006
    #7
  8. I mostly agree, with some of the additions of course being more
    important than others.

    On Sun, 2006-12-31 at 02:27 +0900, Trans wrote:
    > * <code>object_class</code> instead of </code>class</code>. I get sick
    > just looking at <code>self.class.foo</code>. And it prevents use of
    > "class" for other variables/methods. (Hence the all too frequent use of
    > "klass"). <code>object_class</code> on the other hand is nicely
    > analogous to <code>object_id</code>.


    I completely agree here.

    > * Allow a comma between the two <code>alias</code> arguments --getting
    > an error on that is really annoying. Actually why is <code>alias</code>
    > a keyword? Why have both <code>#alias_method</code> and
    > <code>alias</code>? I have always been told that keywords were to be
    > avoided.


    I would personally prefer that the `alias' keyword be removed, but I
    have noticed how at least one prominent Rubyist, which has my utter
    respect, tends to use it all the time. Nonetheless, be gone with it!

    > * A block can't take a block, nor default arguments. What kind of
    > <code>define_method</code> is this? I realize this a trickier issue.
    > But at some point the trick has to be performed.


    +1

    > * Another hassle when metaprogramming. <code>#send</code> should work
    > for public methods only! There's a big issue with backward
    > compatibility here. I have the solution: <code>#object_send</code>.
    > It's a better name anyway b/c it stays out of the way (eg. my Email
    > module would like to have a #send method, you dig?). And #send itself
    > could be deprecated slowly. BTW <code>#funcall</code> for the alternate
    > private-accessing send is a <b>terrible</b> name, try
    > <code>#instance_send</code>. (And yes, I'm begging here!)


    I agree that `funcall' is a weird name... "call a function". What
    function? I thought we agreed on calling them methods!


    Cheers,
    Daniel
     
    Daniel Schierbeck, Dec 30, 2006
    #8
  9. On 12/30/06, Daniel Schierbeck <> wrote:

    > > * Allow a comma between the two <code>alias</code> arguments --getting
    > > an error on that is really annoying. Actually why is <code>alias</code>
    > > a keyword? Why have both <code>#alias_method</code> and
    > > <code>alias</code>? I have always been told that keywords were to be
    > > avoided.

    >
    > I would personally prefer that the `alias' keyword be removed, but I
    > have noticed how at least one prominent Rubyist, which has my utter
    > respect, tends to use it all the time. Nonetheless, be gone with it!


    +1

    I think this is very much a situation where you can easily get by
    without it and avoid ugliness / confusion.
     
    Gregory Brown, Dec 31, 2006
    #9
  10. Trans

    Trans Guest

    Daniel Schierbeck wrote:

    > I agree that `funcall' is a weird name... "call a function". What
    > function? I thought we agreed on calling them methods!


    This is kind of interesting. I don't know if matz had this in mind form
    the beginning or only realized it later, but

    function = private method

    why? because a private method can't be called with a receiver. it's a
    very interesting correlation, which makes excellent sense. however, I
    agree with you, introducing this concept into the language via a single
    meta-coding method called 'funcall' is rather odd, to say the least
    (okay, we have module_function too, but that certainly doesn't help
    matters!!!)

    T.
     
    Trans, Dec 31, 2006
    #10
  11. Trans

    Guest

    Hi --

    On Sun, 31 Dec 2006, Daniel Schierbeck wrote:

    > I agree that `funcall' is a weird name... "call a function". What
    > function? I thought we agreed on calling them methods!


    I think the idea is that calling methods without a receiver can be
    considered "functional style"; therefore, "funcall", rather than
    "send", should be understood to include private methods.

    I'm not sure I find it very convincing. I think of the no-receiver
    thing as a way of un-cluttering the code a bit, not a departure from
    object orientation. After all, there *is* a receiver, and it is
    receiving a message.

    Also, funcall itself does involve a receiver. So the situation is
    that you see this:

    obj.funcall:)meth)

    and you infer that it includes private methods because *if* you were
    calling meth as a private method, there would be no receiver. To me
    that involves too much "What if?"


    David

    --
    Q. What is THE Ruby book for Rails developers?
    A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
    Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
    A. Ruby Power and Light, LLC (http://www.rubypal.com)
     
    , Dec 31, 2006
    #11
  12. unknown wrote:
    > On Sun, 31 Dec 2006, Daniel Schierbeck wrote:
    >
    >> I agree that `funcall' is a weird name... "call a function". What
    >> function? I thought we agreed on calling them methods!

    >
    > I think the idea is that calling methods without a receiver can be
    > considered "functional style"; therefore, "funcall", rather than
    > "send", should be understood to include private methods.


    I think "funcall" is just an artifact of the rb_funcall()
    function---which invokes a method on an _explicit_ receiver---from
    Ruby's C interface.

    --
    Posted via http://www.ruby-forum.com/.
     
    Suraj Kurapati, Dec 31, 2006
    #12
  13. Trans

    Trans Guest

    wrote:
    > Hi --
    >
    > On Sun, 31 Dec 2006, Daniel Schierbeck wrote:
    >
    > > I agree that `funcall' is a weird name... "call a function". What
    > > function? I thought we agreed on calling them methods!

    >
    > I think the idea is that calling methods without a receiver can be
    > considered "functional style"; therefore, "funcall", rather than
    > "send", should be understood to include private methods.
    >
    > I'm not sure I find it very convincing. I think of the no-receiver
    > thing as a way of un-cluttering the code a bit, not a departure from
    > object orientation. After all, there *is* a receiver, and it is
    > receiving a message.
    >
    > Also, funcall itself does involve a receiver. So the situation is
    > that you see this:
    >
    > obj.funcall:)meth)
    >
    > and you infer that it includes private methods because *if* you were
    > calling meth as a private method, there would be no receiver. To me
    > that involves too much "What if?"



    Hmm... Are you perhpas indirectly suggesting:

    send:)meth) # private
    self.send:)meth) # public

    ?

    T.
     
    Trans, Dec 31, 2006
    #13
  14. Trans wrote:
    > Hmm... Are you perhpas indirectly suggesting:
    >
    > send:)meth) # private
    > self.send:)meth) # public
    >
    > ?


    Yikes, a method that behaves differently depending on how it's called?
    What about method:)send).call vs self.method:)send).call?

    Meprefers send_priv or something.

    Devin
    (And I think David was just trying to guess at the reasoning behind the
    name "funcall" [I'd imagine better explained by rb_funcall], and then
    disagreeing with the reasoning.)
     
    Devin Mullins, Dec 31, 2006
    #14
  15. Trans

    Eric Hodel Guest

    On Dec 30, 2006, at 14:47, Daniel Schierbeck wrote:

    > I agree that `funcall' is a weird name... "call a function". What
    > function? I thought we agreed on calling them methods!


    Why? It looks like a function call as there is no receiver.

    obj.foo() # method call, receiver is obj

    foo() # function call, no receiver

    private methods must be called like functions, not like methods.

    --
    Eric Hodel - - http://blog.segment7.net

    I LIT YOUR GEM ON FIRE!
     
    Eric Hodel, Dec 31, 2006
    #15
  16. Trans

    Rob Sanheim Guest

    On 12/31/06, Devin Mullins <> wrote:
    > Trans wrote:
    > > Hmm... Are you perhpas indirectly suggesting:
    > >
    > > send:)meth) # private
    > > self.send:)meth) # public
    > >
    > > ?

    >
    > Yikes, a method that behaves differently depending on how it's called?
    > What about method:)send).call vs self.method:)send).call?
    >
    > Meprefers send_priv or something.
    >
    > Devin


    What about:

    obj.send:)foo) # will call only public
    obj.send!:)foo) # will bypass private/protected, like the current send.

    reads better then funcall to me, at least.
    - Rob
     
    Rob Sanheim, Dec 31, 2006
    #16
  17. On 12/31/06, Rob Sanheim <> wrote:
    > On 12/31/06, Devin Mullins <> wrote:
    > > Trans wrote:
    > > > Hmm... Are you perhpas indirectly suggesting:
    > > >
    > > > send:)meth) # private
    > > > self.send:)meth) # public
    > > >
    > > > ?

    > >
    > > Yikes, a method that behaves differently depending on how it's called?
    > > What about method:)send).call vs self.method:)send).call?
    > >
    > > Meprefers send_priv or something.
    > >
    > > Devin

    >
    > What about:
    >
    > obj.send:)foo) # will call only public
    > obj.send!:)foo) # will bypass private/protected, like the current send.
    >
    > reads better then funcall to me, at least.


    Yes please. That's perfect.
     
    Wilson Bilkovich, Dec 31, 2006
    #17
  18. Trans

    Eric Hodel Guest

    On Dec 31, 2006, at 24:04, Wilson Bilkovich wrote:
    > On 12/31/06, Rob Sanheim <> wrote:
    >> obj.send:)foo) # will call only public
    >> obj.send!:)foo) # will bypass private/protected, like the current
    >> send.
    >>
    >> reads better then funcall to me, at least.

    >
    > Yes please. That's perfect.


    No please. That doesn't match the behavior of any other #foo, #foo!
    that I know of. #send and #funcall match what the written methods
    look like perfectly.

    --
    Eric Hodel - - http://blog.segment7.net

    I LIT YOUR GEM ON FIRE!
     
    Eric Hodel, Dec 31, 2006
    #18
  19. Trans

    Trans Guest

    On Dec 31, 3:34 am, Eric Hodel <> wrote:
    > On Dec 31, 2006, at 24:04, Wilson Bilkovich wrote:
    >
    > > On 12/31/06, Rob Sanheim <> wrote:
    > >> obj.send:)foo) # will call only public
    > >> obj.send!:)foo) # will bypass private/protected, like the current
    > >> send.

    >
    > >> reads better then funcall to me, at least.

    >
    > > Yes please. That's perfect.No please. That doesn't match the behavior of any other #foo, #foo!

    > that I know of. #send and #funcall match what the written methods
    > look like perfectly.


    The problem with #send and #funcall (or #send!) is that these are VIMs
    (very important methods). They aren't to be overwritten lightly, if at
    all, which is evident by the fact that we also have __send__ in case
    that it is. So any generic piece of meta-programming ends up using
    __send__ anyway. Throw in __funcall__ and now we have four methods when
    two would do. So besides the fact that this straddles us with two
    completely different terms for nearly the exact same thing, which is
    bad enough, it does nothing to alleviate this more fundamental issue.

    T.
     
    Trans, Dec 31, 2006
    #19
  20. Trans

    Guest

    Hi --

    On Sun, 31 Dec 2006, Rob Sanheim wrote:

    > On 12/31/06, Devin Mullins <> wrote:
    >> Trans wrote:
    >> > Hmm... Are you perhpas indirectly suggesting:
    >> >
    >> > send:)meth) # private
    >> > self.send:)meth) # public
    >> >
    >> > ?

    >>
    >> Yikes, a method that behaves differently depending on how it's called?
    >> What about method:)send).call vs self.method:)send).call?
    >>
    >> Meprefers send_priv or something.
    >>
    >> Devin

    >
    > What about:
    >
    > obj.send:)foo) # will call only public
    > obj.send!:)foo) # will bypass private/protected, like the current send.
    >
    > reads better then funcall to me, at least.


    Me too -- that was what I suggested long ago :) Matz didn't feel it
    corresponded to his concept of a ! (dangerous) method.


    David

    --
    Q. What is THE Ruby book for Rails developers?
    A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
    Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
    A. Ruby Power and Light, LLC (http://www.rubypal.com)
     
    , Dec 31, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin Spencer

    Re: VS thinks it knows things better

    Kevin Spencer, Jun 27, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    404
    Kevin Spencer
    Jun 27, 2003
  2. =?Utf-8?B?V2lsbGlhbSBTdWxsaXZhbg==?=

    vs2005 publish website doing bad things, bad things

    =?Utf-8?B?V2lsbGlhbSBTdWxsaXZhbg==?=, Oct 25, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    606
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Oct 25, 2006
  3. ThaDoctor
    Replies:
    3
    Views:
    385
    Alan Woodland
    Sep 28, 2007
  4. David Heinemeier Hansson
    Replies:
    0
    Views:
    107
    David Heinemeier Hansson
    Oct 26, 2005
  5. Daniel
    Replies:
    1
    Views:
    214
    Bart van Ingen Schenau
    Jul 9, 2013
Loading...

Share This Page