Trip down memory lane...

Discussion in 'Ruby' started by David A. Black, Nov 8, 2009.

  1. David A. Black, Nov 8, 2009
    #1
    1. Advertising

  2. On Sun, 8 Nov 2009, David A. Black wrote:

    > Hi --
    >
    > I've been hunting through old RCRs, and came across my favorite
    > rejected one:
    >
    > http://oldrcrs.rubypal.com/rejected.html#rcr120


    And its near-relation:

    http://oldrcrs.rubypal.com/rejected.html#rcr94

    > :) Still trying to find that map:)sym) one....


    Found it! See map:)sym) thread....


    David

    --
    The Ruby training with D. Black, G. Brown, J.McAnally
    Compleat Jan 22-23, 2010, Tampa, FL
    Rubyist http://www.thecompleatrubyist.com

    David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)
    David A. Black, Nov 8, 2009
    #2
    1. Advertising

  3. On 8 Nov 2009, at 15:41, David A. Black wrote:
    > On Sun, 8 Nov 2009, David A. Black wrote:
    >
    >> Hi --
    >>
    >> I've been hunting through old RCRs, and came across my favorite
    >> rejected one:
    >>
    >> http://oldrcrs.rubypal.com/rejected.html#rcr120

    >
    > And its near-relation:
    >
    > http://oldrcrs.rubypal.com/rejected.html#rcr94


    I always wanted http://oldrcrs.rubypal.com/rejected.html#rcr2 - but
    then again I also want goal direction to scratch my (un)icon itches :)


    Ellie

    Eleanor McHugh
    Games With Brains
    http://slides.games-with-brains.net
    ----
    raise ArgumentError unless @reality.responds_to? :reason
    Eleanor McHugh, Nov 8, 2009
    #3
  4. On Sunday 08 November 2009 08:32:53 am David A. Black wrote:
    > Hi --
    >
    > I've been hunting through old RCRs, and came across my favorite
    > rejected one:
    >
    > http://oldrcrs.rubypal.com/rejected.html#rcr120


    Actually, it looks like rcr124 was eventually accepted as BasicObject, right?

    I can see why rcr147 was rejected, but it's not entirely without precedent --
    see .profile for sh and bash.

    And rcr169, I actually like. What if the exception was raised deep in another
    method, but it's something you can handle? Also not without precedent, as Lisp
    has these.

    Not to re-open old discussions, I just thought it was interesting --
    especially #124, which was rejected, and is now implemented. Seems the
    rejection isn't final.
    David Masover, Nov 8, 2009
    #4
  5. On Mon, 9 Nov 2009, David Masover wrote:

    > On Sunday 08 November 2009 08:32:53 am David A. Black wrote:
    >> Hi --
    >>
    >> I've been hunting through old RCRs, and came across my favorite
    >> rejected one:
    >>
    >> http://oldrcrs.rubypal.com/rejected.html#rcr120

    >
    > Actually, it looks like rcr124 was eventually accepted as BasicObject, right?


    It's a little different: the reason for rejection was:

    See technique used in delegate.rb for such purpose.

    as opposed to the reason for rejection of 120, which was:

    No, it should not.

    :) Also, though I can't remember the details, I seem to remember that
    Matz actually suggested that someone submit such an RCR so that he
    could comment definitively on the matter and spare everyone from
    revisiting the question over and over again.

    > I can see why rcr147 was rejected, but it's not entirely without precedent --
    > see .profile for sh and bash.
    >
    > And rcr169, I actually like. What if the exception was raised deep in another
    > method, but it's something you can handle? Also not without precedent, as Lisp
    > has these.


    True, but the business of precedents from other languages sort of
    cancels itself out, since it encompasses literally tens or hundreds of
    thousands of features, large and small. Of course lots of Ruby
    features are adopted or adapted from other languages; but I don't
    think the presence of a feature or practice in another language,
    per se, militates in favor of its inclusion in Ruby.

    > Not to re-open old discussions, I just thought it was interesting --
    > especially #124, which was rejected, and is now implemented. Seems the
    > rejection isn't final.


    I think the BasicObject concept (unlike the putting-class-names-in-
    method-signatures concept) was bubbling under the surface for a long
    time, and appeared in various incarnations, including the delegate.rb
    technique that Matz referred to as well as Jim Weirich's BlankSlate
    class, before being adopted into the family tree. It wasn't a case of
    something fundamentally out of character for the language. Not all RCR
    rejection is created equal :) (And part of that, too, is of course
    that Matz can change his mind over time.)


    David

    --
    The Ruby training with D. Black, G. Brown, J.McAnally
    Compleat Jan 22-23, 2010, Tampa, FL
    Rubyist http://www.thecompleatrubyist.com

    David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)
    David A. Black, Nov 8, 2009
    #5
  6. Brian Candler, Nov 9, 2009
    #6
  7. On 9 Nov 2009, at 14:27, Brian Candler wrote:
    > Eleanor McHugh wrote:
    >> I always wanted http://oldrcrs.rubypal.com/rejected.html#rcr2 - but
    >> then again I also want goal direction to scratch my (un)icon
    >> itches :)

    >
    > Is that more or less what Fiber is in 1.9 ?


    It could be viewed that way, however a closer analogue to icon's usage
    would be for all blocks to be generators without recourse to an OO
    abstraction. However that's an ancient argument and probably not worth
    reopening.

    Thinking about it though I could probably build an icon-style goal-
    directed evaluator using Fiber and wrap it in a DSL that would make
    coding with it feel very very similar. I'll have to take a look at
    that when I have some free time to play with.


    Ellie

    Eleanor McHugh
    Games With Brains
    http://slides.games-with-brains.net
    ----
    raise ArgumentError unless @reality.responds_to? :reason
    Eleanor McHugh, Nov 9, 2009
    #7
  8. On Sunday 08 November 2009 03:44:15 pm David A. Black wrote:
    > On Mon, 9 Nov 2009, David Masover wrote:


    > > I can see why rcr147 was rejected, but it's not entirely without
    > > precedent -- see .profile for sh and bash.
    > >
    > > And rcr169, I actually like. What if the exception was raised deep in
    > > another method, but it's something you can handle? Also not without
    > > precedent, as Lisp has these.

    >
    > True, but the business of precedents from other languages sort of
    > cancels itself out, since it encompasses literally tens or hundreds of
    > thousands of features, large and small.


    My point wasn't that it had _ever_ been done, but that it had been done well,
    and had been found to be useful. For example, while I could simply include a
    list of environment variables somewhere, or tweak the bash commandline from
    /etc/passwd, it's much more convenient to be able to use actual shell logic in
    /etc/profile and .profile to set those variables.

    Yes, it _can_ screw things up, if misused. I don't think that's a reason not
    to do it.

    Similarly, Lisp restarts, when I read gigamonkeys.com/book, seemed to be
    really useful and something I'd miss in Ruby. In the book's example, he's got
    a log parser, with two restarts: parse-log-entry and skip-log-entry. That is,
    you could do something roughly equivalent to this:

    begin
    logfile = LogParser.parse('/some/file')
    rescue LogParser::MalformedEntry
    entry = $!.text
    if entry =~ /some_regex/
    restart :reparse, entry.gsub(/some/, 'substitution')
    else
    restart :skip
    end
    end

    I'm not attached to that syntax (actually, the 'restart' in particular looks
    cumbersome), but the point is that this is much more flexible than something
    like this:

    LogParser.parse('/some/file', :skip_malformed => true, :fix_bad_entry => proc{|
    x| x.gsub(/some/, 'substitution')})

    First, that's not quite equivalent (and it's a little ugly). Second, it's much
    nicer to be able to actually separate the error handling logic.

    And finally, one of the main points of exceptions -- to me, at least -- is that
    you don't need to have specific error-handling logic within each method that
    might throw an error. (This is something Java gets horribly wrong, by the way
    -- having to manually specify "throws" almost defeats the purpose.) It means
    the error _will_ be handled, even if it's somewhere much farther up the call
    stack, even if "handling" means aborting the program rather than letting an
    error be silently ignored.

    So, it makes sense that if the error actually can be corrected up the call
    stack, it should be. For example:

    def foo
    ...
    LogParser.parse ...
    ...
    end

    begin
    foo
    rescue LogParser::MalformedEntry
    ...
    end

    The closest thing we currently have is "retry", which re-runs the entire
    block. Obviously, this isn't a good idea if we're halfway through a multi-
    gigabyte log, and it doesn't help us actually correct the error.

    Am I missing something obvious? Maybe a design pattern which avoids this, or
    maybe a way to implement the equivalent without changing Ruby itself?

    > I think the BasicObject concept (unlike the putting-class-names-in-
    > method-signatures concept) was bubbling under the surface for a long
    > time... It wasn't a case of
    > something fundamentally out of character for the language. Not all RCR
    > rejection is created equal :) (And part of that, too, is of course
    > that Matz can change his mind over time.)


    That was the impression I got there. I was pointing it out partly just to make
    sure I wasn't crazy, and that this was indeed a rejected BasicObject idea.
    David Masover, Nov 10, 2009
    #8
    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. Peter Row
    Replies:
    1
    Views:
    683
    vMike
    Nov 26, 2003
  2. =?Utf-8?B?WWFuaXI=?=

    Sort table without round trip

    =?Utf-8?B?WWFuaXI=?=, Apr 6, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    726
    Steve Drake
    Apr 6, 2004
  3. Rathtap
    Replies:
    2
    Views:
    496
    Janaka
    Aug 24, 2004
  4. Replies:
    8
    Views:
    433
    =?Utf-8?B?TWF0SGVydGVs?=
    Oct 8, 2005
  5. Jan

    Byte lane select

    Jan, Oct 18, 2008, in forum: VHDL
    Replies:
    4
    Views:
    1,625
Loading...

Share This Page