[ruby-core:35868] Re: [Ruby 1.9 - Feature #4102] Proposal for 'let'. A new approach using block-defaults in 1.9

You can use begin/end-blocks or #tap:

    # Begin
    def fnames
      @fnames ||= begin
        hash = Hash.new { |h,k| k = k.to_s; h[k] = generate_fname(k) }
        def hash.[](key)
          super(key.to_s)
        end
        def hash.[]=(key, value)
          super(key.to_s, value)
        end
        hash
      end
    end

    # Tap
    def fnames
      @fnames ||= Hash.new { |h,k| k = k.to_s; h[k] = generate_fname(k)
}.tap do |hash|
        def hash.[](key)
          super(key.to_s)
        end
        def hash.[]=(key, value)
          super(key.to_s, value)
        end
      end
    end


// Magnus Holm


On Sun, Apr 24, 2011 at 08:07, Tom Wardrop <[e-mail]> wrote:

>
> Issue #4102 has been updated by Tom Wardrop.
>
>
> Here's an example I just encountered where #let (a self executing proc)
> would have been useful. Here's a method I've just defined in a project I'm
> working on, including how that same method would look with #let.
>
> http://pastie.org/1827489
>
> The difference is small (does away with the #call at the end), but it
> results in cleaner and clearer code. It can be easy to miss the #call method
> at the end of the proc, as it's just not something you're use to seeing.
>
> I find the main use case for #let is where you want to do something
> mid-expression. In this example, I want to define a method on a new object
> as part of an ||= assignment.
> ----------------------------------------
> Feature #4102: Proposal for 'let'. A new approach using block-defaults in
> 1.9
> http://redmine.ruby-lang.org/issues/4102
>
> Author: john mair
> Status: Open
> Priority: Normal
> Assignee:
> Category:
> Target version:
>
>
>  This is a very simple function, it would be implemented as follows:
>
>     module Kernel
>       private
>       def let() yield end
>     end
>
>  First of all, do not dismiss this functionality out of hand because of
>  its simplicity.
>
>  Even though it is just a 'yield', when it is combined with Ruby 1.9's
>  block defaults and new block-variable scoping rules it is actually quite
>  powerful and it behaves exactly like a let* in lisp.
>
>  Some advantages of this functionality are:
>  (1) Gives you precise control over the scope of your variables.
>
>  I note that after the publication of "Metaprogramming in Ruby" by Paolo
>  Perrotta the following idiom has started to appear:
>
>     proc do
>       ..my code..
>     end.call
>
>  It is used exactly as the proposed 'let' would be used, but is
>  syntactically much uglier.
>
>  Yes, i know an alternative is to just make shorter and smaller methods.
>  But is the ability to control and restrict scope ever a bad thing?
>
>  (2) Testing and teaching about blocks.
>
>  As the proposed 'let' simply yields to a block it can be used to
>  illustrate block behaviour and block concepts to a new Ruby programmer.
>  It also may be useful to an experienced programmer when trying out new
>  ideas.
>
>  Here are some example uses of the proposed 'let':
>
>  Example 1: Carve out a temporary scope, make 'x' local to that scope
>
>     x = :outer
>     let { |x| x = :inner } #=> :inner
>     x #=> :outer
>
>  Example 2: Here we use Ruby 1.9's block-defaults to make 'y' block-local
>  and give it a value:
>
>     let { |y=10| y } #=> 10
>
>  Example 3: Make 'x' and 'y' block-local and have 'y' value depend on 'x'
>  (equivalent to let* in lisp)
>
>     let { |x=10, y=(2*x)| [x, y] } #=> [10, 20]
>
>  In summary, I think this proposal should succeed for the following
>  reasons:
>  (1) It is an exceptionally simple implementation.
>  (2) More control over scope is never a bad thing.
>  (3) I have seen people re-implementing this functionality themselves
>  using: proc { ..code.. }.call
>  (4) It is very useful for teaching and testing block behaviour.
>
>  Thanks,
>
>  John
>
>
> --
> http://redmine.ruby-lang.org
>
>