ruby-dev summary 17252-17356

Hi all,

This is a summary of ruby-dev ML in these days.

---- ruby-dev #17252-17356 (2002-06-01 ... 2002-06-07) ----

[ruby-dev:17228] ((1.2)..(3.4)).to_a (contd.)

  Conclusion: (from ChangeLog)

  Thu May 30 12:52:42 2002  Yukihiro Matsumoto  <[e-mail]>

	* range.c (range_step): iteration done using "+" if elements are
	  Numeric.  Otherwise using "succ".

	* range.c (range_each): iteration done using "succ".  If the
	  elements does not respond to "succ", raise TypeError.  As a
	  result, all Enumerable methods, e.g. collect, require elements
	  to respond to "succ".

	* range.c (range_member): comparison done using "each", if
	  elements are non-Numeric or no-"succ" objects.  Otherwise
	  compare using "<=>".

	* range.c (Init_Range): remove "size" and "length".


[ruby-dev:17271] IO#stat

  Wakou Aoyama has asked why IO#stat exists, instead of File#stat.
  Matz's answer: Ruby is based on UNIX. IO represents UNIX's file
  descripter, so IO#stat is natural.

[ruby-dev:17276] blocks and local variables

  Takaaki Tateishi has requested "true" block local variable.

  * Backward compatibility takes precedence over all.

  * The problem is that block localization may be broken with
    name collision between inside of the block and the outside.

  * It is not true that ruby does not have block local variables.
    The problem is that local variables does NOT shadows outer
    local variables.

  * We must think about both of block parameters and block local
    variables.  e.g.

      lambda {|a|   # a is block parameter.
	  b = nil   # b is block variable.
      }

  * a candidate of declaration of block local parameter

      lambda {<a>    # a is block patemeter which is block local
	  ....
      }

  * There's two strategies to declare that variables are block local.
    (1) using block parameter declarations. e.g.

      lambda {<a,b,c; x,y>    # x, y is block local
	  ....
      }

    (2) using special form of assignment

      x := nil    # x is block local


  This issue is still open.

[ruby-dev:17329] parsedate: extend or not

  Tadayoshi Funaba wants public comments on his library, parsedate.rb.
  Current parsedate.rb does "U.S. friendly" parsing, and non-few
  people want support of their own locales. But it is impossible to
  support all local formats at the same time. At least we will have
  to tell desired formats to the parser. Note that single locale
  system is useless here, because we will want to parse more than
  one format at the same time.

  Should we extend the library, or keep the library simple?