Professional Web Applications Themes

proposal: let kind_of take more arguments - Ruby

It just hit me.. why not let kind_of? take more arguments? irb(main):001:0> x = 3 => 3 irb(main):002:0> x.kind_of?(String) => false irb(main):003:0> x.kind_of?(String, Fixnum) ArgumentError: wrong number of arguments(2 for 1) from (irb):3:in `kind_of?' from (irb):3 irb(main):004:0> For instance I have def push(choice) if choice.kind_of?(Zero) == false and choice.kind_of?(One) == false raise "got #{choice.class}" end choices << choice end It could turn into def push(choice) unless choice.kind_of?(Zero, One) raise "got #{choice.class}" end choices << choice end -- Simon Strandgaard...

  1. #1

    Default proposal: let kind_of take more arguments

    It just hit me.. why not let kind_of? take more arguments?

    irb(main):001:0> x = 3
    => 3
    irb(main):002:0> x.kind_of?(String)
    => false
    irb(main):003:0> x.kind_of?(String, Fixnum)
    ArgumentError: wrong number of arguments(2 for 1)
    from (irb):3:in `kind_of?'
    from (irb):3
    irb(main):004:0>



    For instance I have

    def push(choice)
    if choice.kind_of?(Zero) == false and choice.kind_of?(One) == false
    raise "got #{choice.class}"
    end
    choices << choice
    end


    It could turn into

    def push(choice)
    unless choice.kind_of?(Zero, One)
    raise "got #{choice.class}"
    end
    choices << choice
    end


    --
    Simon Strandgaard
    Simon Guest

  2. #2

    Default Re: proposal: let kind_of take more arguments


    "Simon Strandgaard" <dk> schrieb im Newsbeitrag
    news:dk... 

    Never compare boolean values to get boolean values. This can lead to
    hideous bugs if the method at hand does not return "true" or "false" -
    especially with languages that have more than one value for either.
     

    ArgumentError is a good choice here. :-)
     

    Why don't you just do

    def push(choice)
    case choice
    when Zero, One
    choices << choice
    else
    raise ArgumentError, "got #{choice.class}"
    end
    end

    or

    def push(choice)
    raise ArgumentError, "got #{choice.class}" unless [Zero,
    One].map{|cl|choice.kind_of? cl}.any?
    choices << choice
    end

    or

    class Object
    def kind_of_any?( *classes )
    classes.each{|cl| return true if kind_of? cl}
    false
    end
    end

    Then:

    def push(choice)
    raise ArgumentError, "got #{choice.class}" unless
    choice.kind_of_any?(Zero, One)
    choices << choice
    end

    Regards

    robert

    Robert Guest

  3. #3

    Default Re: proposal: let kind_of take more arguments

    On Thu, 19 Feb 2004 15:43:05 +0100, Robert Klemme wrote: 
    >
    > Never compare boolean values to get boolean values. This can lead to
    > hideous bugs if the method at hand does not return "true" or "false" -
    > especially with languages that have more than one value for either.[/ref]

    Thanks for the warning. I have actually had a few problems with it
    earlier, without realizing this.

     
    >
    > ArgumentError is a good choice here. :-)[/ref]

    I don't have full overview over Ruby's exception hierarchy, but yes
    I should use this one here (which I do now). ;-)
     
    >
    > Why don't you just do
    >
    > def push(choice)
    > case choice
    > when Zero, One
    > choices << choice
    > else
    > raise ArgumentError, "got #{choice.class}"
    > end
    > end[/ref]

    a switch statement.. easier to read.
    However I like to do bailout as soon as possible,
    raising ArgumentError this late may make confusion.


     

    Confusion :-)



     

    Yes thought of this.. which maked me propose this idea.

    --
    Simon Strandgaard

    Simon Guest

  4. #4

    Default Re: proposal: let kind_of take more arguments


    "Simon Strandgaard" <dk> schrieb im Newsbeitrag
    news:dk... 
    > >
    > > Never compare boolean values to get boolean values. This can lead to
    > > hideous bugs if the method at hand does not return "true" or "false" -
    > > especially with languages that have more than one value for either.[/ref]
    >
    > Thanks for the warning. I have actually had a few problems with it
    > earlier, without realizing this.[/ref]

    :-))

    I forgot to mention, that it's totally superfluous, too, and thus may cost
    you some machine cycles... :-))
     
    > >
    > > ArgumentError is a good choice here. :-)[/ref]
    >
    > I don't have full overview over Ruby's exception hierarchy, but yes
    > I should use this one here (which I do now). ;-)[/ref]

    :-))
     
    > >
    > > Why don't you just do
    > >
    > > def push(choice)
    > > case choice
    > > when Zero, One
    > > choices << choice
    > > else
    > > raise ArgumentError, "got #{choice.class}"
    > > end
    > > end[/ref]
    >
    > a switch statement.. easier to read.
    > However I like to do bailout as soon as possible,
    > raising ArgumentError this late may make confusion.[/ref]

    What do you mean by "late"? Do you mean that the line with "raise" stands
    below the actual operation. Didn't think of that, but yes, it might be
    confusing. OTOH, if you can read "case" then it's not so difficult, is
    it?
     
    >
    > Confusion :-)[/ref]

    http://lyricsheaven.topcities.com/survey_d_k_bestanden/ELO.htm#confusion
     
    >
    > Yes thought of this.. which maked me propose this idea.[/ref]

    I'm wondering though whether it's worth the effort. When using duck
    typing, you don't need kind_of? anyway.

    Btw, I had another idea:

    PUSH_ALLOWED = {Zero, One}

    def push(choice)
    raise ArgumentError, "got #{choice.class}" unless
    PUSH_ALLOWED[choice.class]
    choices << choice
    end

    Of course there is a subtle difference since this does not take sub
    classes into consideration. But other than that, it should be faster -
    especially if you have more classes that shoule be checked.

    :-)

    Kind regards

    robert

    Robert Guest

  5. #5

    Default Re: proposal: let kind_of take more arguments

    On Thu, 19 Feb 2004, Robert Klemme wrote:
     
    >
    > Never compare boolean values to get boolean values. This can lead to
    > hideous bugs if the method at hand does not return "true" or "false" -
    > especially with languages that have more than one value for either.[/ref]


    what do you reccomend (when a case won't do) ?

    ....
    unless choice.kind_of?(Zero) or choice.kind_of?(One)
    ....

    -a
    --
    ================================================== =============================
    | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
    | PHONE :: 303.497.6469
    | ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
    | URL :: http://www.ngdc.noaa.gov/stp/
    | TRY :: for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done
    ================================================== =============================

    Ara.T.Howard Guest

  6. #6

    Default Re: proposal: let kind_of take more arguments

    On Thu, 19 Feb 2004, Simon Strandgaard wrote:
     

    this is a good idea regardless of your exact situation - it reads nicer than a
    case, which i generally use for this

    -a
     

    --
    ================================================== =============================
    | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
    | PHONE :: 303.497.6469
    | ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
    | URL :: http://www.ngdc.noaa.gov/stp/
    | TRY :: for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done
    ================================================== =============================

    Ara.T.Howard Guest

  7. #7

    Default Re: proposal: let kind_of take more arguments

    On Thu, 19 Feb 2004 16:14:13 +0100, Robert Klemme wrote: 
    >>
    >> a switch statement.. easier to read.
    >> However I like to do bailout as soon as possible,
    >> raising ArgumentError this late may make confusion.[/ref]
    >
    > What do you mean by "late"? Do you mean that the line with "raise" stands
    > below the actual operation. Didn't think of that, but yes, it might be
    > confusing. OTOH, if you can read "case" then it's not so difficult, is
    > it?[/ref]

    It isn't clear at first sight when the method bailouts, and if
    the switch statement spans over many lines, then its not visible at all
    that its capable of raising exceptions.

    Kind_of? similar to bouncer pattern, see
    http://www.rubygarden.org/ruby?BouncerPattern

     
    >
    > http://lyricsheaven.topcities.com/survey_d_k_bestanden/ELO.htm#confusion[/ref]

    :-)

     
    >>
    >> Yes thought of this.. which maked me propose this idea.[/ref]
    >
    > I'm wondering though whether it's worth the effort. When using duck
    > typing, you don't need kind_of? anyway.
    >
    > Btw, I had another idea:
    >
    > PUSH_ALLOWED = {Zero, One}
    >
    > def push(choice)
    > raise ArgumentError, "got #{choice.class}" unless
    > PUSH_ALLOWED[choice.class]
    > choices << choice
    > end[/ref]

    Good idea, but gives a complex impression at first sight.

     

    Im in the make it work phase.

    There is 3 phases:
    1) make it work
    2) make it right
    3) make it fast ;-)

    --
    Simon Strandgaard
    Simon Guest

  8. #8

    Default Re: proposal: let kind_of take more arguments

    On Thu, 19 Feb 2004 08:19:33 -0700, Ara.T.Howard wrote: 

    My brain is terrible at dealing with 'unless'.
    If its just "unless something" then its ok.
    But when its "unless a or b and c" then it chokes.

    Am I the only one feeling like this?

    Where can I seek help ? ;-)

    --
    Simon Strandgaard
    Simon Guest

  9. #9

    Default Re: proposal: let kind_of take more arguments

    On Thu, 19 Feb 2004, Simon Strandgaard wrote:
     
    >
    > My brain is terrible at dealing with 'unless'.
    > If its just "unless something" then its ok.
    > But when its "unless a or b and c" then it chokes.
    >
    > Am I the only one feeling like this?
    >
    > Where can I seek help ? ;-)[/ref]

    a digital logic book, the simplest, will help. de morgan's laws..., eg.

    noting that 'unless' is the negation of 'if', in otherwords 'unless' => 'if
    not'

    let

    ^ => and

    v => or

    ~ => negation

    Z => kind_of? Zero

    O => kind_of? One

    then we can say your original statement

    choice.kind_of?(Zero) == false and choice.kind_of?(One) == false

    as simply

    ~Z ^ ~O

    if we want use this conjunction in the negative sense (convert to 'unless')
    we can convert using the following heuristic 'negate each clause and flip
    the operation'

    so

    ~(~Z ^ ~O) => Z v 0

    or

    choice.kind_of?(Zero) or choice.kind_of?(One)


    now we have the _negation_ of the conjuction. this is want we want though
    since were are trying to use it in the negative sense (unless). eg. we're
    done:

    unless choice.kind_of?(Zero) or choice.kind_of?(One)
    ...
    end


    if you express in simple terms it's pretty easy. eg.

    HTH.

    -a
    --
    ================================================== =============================
    | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
    | PHONE :: 303.497.6469
    | ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
    | URL :: http://www.ngdc.noaa.gov/stp/
    | TRY :: for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done
    ================================================== =============================


    Ara.T.Howard Guest

  10. #10

    Default Re: proposal: let kind_of take more arguments


    "Ara.T.Howard" <ngdc.noaa.gov> schrieb im Newsbeitrag
    news:ngdc.noaa.gov... [/ref][/ref]
    false 
    >
    >
    > what do you reccomend (when a case won't do) ?
    >
    > ...
    > unless choice.kind_of?(Zero) or choice.kind_of?(One)
    > ...[/ref]

    Exactly. Boolean operators are for transformation of boolean values.
    Comparison with 'true', 'false', 'nil' or whatever is not appropriate for
    the stated reasons.

    :-)

    robert

    Robert Guest

  11. #11

    Default Re: proposal: let kind_of take more arguments


    "Simon Strandgaard" <dk> schrieb im Newsbeitrag
    news:dk... 
    > >
    > > What do you mean by "late"? Do you mean that the line with "raise"[/ref][/ref]
    stands [/ref]
    be [/ref]
    is 
    >
    > It isn't clear at first sight when the method bailouts, and if
    > the switch statement spans over many lines, then its not visible at all
    > that its capable of raising exceptions.
    >
    > Kind_of? similar to bouncer pattern, see
    > http://www.rubygarden.org/ruby?BouncerPattern[/ref]

    I see, you want to save the extra method check_arg_xyz(). :-)
     
    > >
    > >[/ref][/ref]
    http://lyricsheaven.topcities.com/survey_d_k_bestanden/ELO.htm#confusion 
    > >
    > > I'm wondering though whether it's worth the effort. When using duck
    > > typing, you don't need kind_of? anyway.
    > >
    > > Btw, I had another idea:
    > >
    > > PUSH_ALLOWED = {Zero, One}
    > >
    > > def push(choice)
    > > raise ArgumentError, "got #{choice.class}" unless
    > > PUSH_ALLOWED[choice.class]
    > > choices << choice
    > > end[/ref]
    >
    > Good idea, but gives a complex impression at first sight.[/ref]

    Really? PUSH_ALLOWED[choice.class] looks pretty much like a method call
    to me... And it's blindingly fast even for large amounts of classes.
    Well, I guess it's a matter of taste then...

    You could also use a Set for this like in

    require 'Set'
    PUSH_ALLOWED = Set.new([Zero, One])

    def push(choice)
    raise ArgumentError, "got #{choice.class}" unless
    PUSH_ALLOWED.include? choice.class

    choices << choice
    end

    Did I say there are tons of ways in Ruby? :-))
     [/ref]
    faster - 
    >
    > Im in the make it work phase.
    >
    > There is 3 phases:
    > 1) make it work
    > 2) make it right
    > 3) make it fast ;-)[/ref]

    :-)))

    Have fun!

    robert

    Robert Guest

  12. #12

    Default Re: proposal: let kind_of take more arguments

    On Thu, 19 Feb 2004 09:30:16 -0700, Ara.T.Howard wrote: 
    >>
    >> My brain is terrible at dealing with 'unless'.
    >> If its just "unless something" then its ok.
    >> But when its "unless a or b and c" then it chokes.
    >>
    >> Am I the only one feeling like this?
    >>
    >> Where can I seek help ? ;-)[/ref]
    >
    > a digital logic book, the simplest, will help. de morgan's laws..., eg.[/ref]
    [snip talk about de morgans law]

    Yes I know these rules.. also karnough maps helps gaining overview of
    boolean operations. When an expression gets too complex then I like
    place a comment with the corresponding karnough map.

    What I should have said was that I grew up with 'if then else'.
    The 'unless' keyword is a recent addition to my vocabulary, I am still
    a bit rusty in its usage.

    --
    Simon Strandgaard
    Simon Guest

  13. #13

    Default Re: proposal: let kind_of take more arguments

    On Thu, 19 Feb 2004, Simon Strandgaard wrote:
     
    > >
    > > a digital logic book, the simplest, will help. de morgan's laws..., eg.[/ref]
    > [snip talk about de morgans law]
    >
    > Yes I know these rules.. also karnough maps helps gaining overview of
    > boolean operations. When an expression gets too complex then I like
    > place a comment with the corresponding karnough map.
    >
    > What I should have said was that I grew up with 'if then else'.
    > The 'unless' keyword is a recent addition to my vocabulary, I am still
    > a bit rusty in its usage.[/ref]

    ah. i got it from a the 'p' language - one of the good things about it IMHO.
    ;-)

    -a
    --
    ================================================== =============================
    | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
    | PHONE :: 303.497.6469
    | ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
    | URL :: http://www.ngdc.noaa.gov/stp/
    | TRY :: for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done
    ================================================== =============================

    Ara.T.Howard Guest

  14. #14

    Default Re: [RCR] kind_of class'es (was: proposal: let kind_of take more arguments)

    On Thu, 19 Feb 2004 08:21:23 -0700, Ara.T.Howard wrote: 
    >
    > this is a good idea regardless of your exact situation - it reads nicer than a
    > case, which i generally use for this
    >[/ref]

    Ok, glad you like it. I have submitted an RCR of it,
    please vote on it.

    http://rcrchive.net/rcr/RCR/RCR218

    --
    Simon Strandgaard
    Simon Guest

  15. #15

    Default Re: proposal: let kind_of take more arguments


    "Simon Strandgaard" <dk> schrieb im Newsbeitrag
    news:dk... 
    > >
    > > a digital logic book, the simplest, will help. de morgan's laws...,[/ref][/ref]
    eg. 

    .... unless you use it more and more: this will accustom you to the u-word.

    :-))

    robert

    Robert Guest

  16. #16

    Default Re: proposal: let kind_of take more arguments

    Hi,

    At Fri, 20 Feb 2004 20:20:09 +0900,
    Simon Strandgaard wrote in [ruby-talk:93193]: 

    unless [Zero, One].any? {|klass| choice.kind_of?(klass)}

    Or shorter

    unless [Zero, One].any?(&choice.method(:kind_of?)

    --
    Nobu Nakada


    nobu.nokada@softhome.net Guest

  17. #17

    Default Re: proposal: let kind_of take more arguments

    On Thu, 19 Feb 2004 18:21:47 +0100, Robert Klemme wrote: 
    >>
    >> It isn't clear at first sight when the method bailouts, and if
    >> the switch statement spans over many lines, then its not visible at all
    >> that its capable of raising exceptions.
    >>
    >> Kind_of? similar to bouncer pattern, see
    >> http://www.rubygarden.org/ruby?BouncerPattern[/ref]
    >
    > I see, you want to save the extra method check_arg_xyz(). :-)
    >[/ref]

    Yes, it depends on if its understandable at first sight and isn't
    too visually disturbing. The concept of minimizing visual noise.

    If it isn't clear what is going on, then turn that piece of code into a
    check_something method.

    If the 'if-statement' is simple, then I typically don't make a
    check_something method out of that.

    --
    Simon Strandgaard
    Simon Guest

  18. #18

    Default Re: proposal: let kind_of take more arguments

    Hi,

    In message "proposal: let kind_of take more arguments"
    on 04/02/20, Simon Strandgaard <dk> writes:

    |It just hit me.. why not let kind_of? take more arguments?

    kinf_of? method easily hinders "duck typing", so that I don't feel
    good to make it easier to use.

    matz.


    Yukihiro Guest

  19. #19

    Default Re: proposal: let kind_of take more arguments

    net wrote: 

    Or, as I noted on the RCR:

    unless ([Zero,One] & choice.class.ancestors).length>0

    --
    (-, /\ \/ / /\/
    Gavin Guest

  20. #20

    Default Re: proposal: let kind_of take more arguments


    "Gavin Kistner" <com> schrieb im Newsbeitrag
    news:3boZb.87208$.. 
    >
    > Or, as I noted on the RCR:
    >
    > unless ([Zero,One] & choice.class.ancestors).length>0[/ref]

    if ([Zero,One] & choice.class.ancestors).empty?

    :-))
     

    Robert Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. [RFC] 'via' proposal
    By Elias in forum Ruby
    Replies: 2
    Last Post: February 10th, 07:24 AM
  2. Replies: 9
    Last Post: December 15th, 03:34 AM
  3. 'with' proposal
    By Elias Athanasopoulos in forum Ruby
    Replies: 4
    Last Post: November 22nd, 06:44 PM
  4. Replies: 0
    Last Post: October 24th, 12:01 AM
  5. OT: a proposal...
    By Victoria in forum Macromedia Dreamweaver
    Replies: 10
    Last Post: July 31st, 06:35 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139