Hi all,

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

[ruby-dev:20392] [BigDecimal] proposal to change specification
[ruby-dev:20447] [BigDecimal] renaming proposal
[ruby-dev:20525] [BigDecimal] changing rule of coerce
[ruby-dev:20637] [BigDecimal] bundling issues
[ruby-dev:20644] [BigDecimal] dup and to_f
(contd.)

  Tadashi Saito and many people proposed numerous enhancement about
  BigDecimal.  Their proposals and responses:
  (Some entries are duplicated with a previous summary, [ruby-talk:74878])

  * adding new method BigDecimal#** (alias of #power)

  -> Accepted.

  * BigDecimal#infinite? should return 1/-1/nil instead of true/false.
    (1 for INF, -1 for -INF, nil for non-INF)

  -> Accepted.

  * BigDecimal#nonzero? should return self/nil instead of true/false,
    to be consistent with Numeric#nonzero?.

      % ruby -e 'p 3.nonzero?'   #=> 3
      % ruby -e 'p 0.nonzero?'   #=> nil

  -> Accepted.

  * removing BigDecimal#sign. Reasons:
      1. It does not exist on other Numeric classes.
      2. #sign returns 7 constants for NaN/+0/-0/+/-/+INF/-INF,
         but the method name "sign" is not appropriate for such aim.

  -> Accepted.

  * renaming BigDecimal#to_parts to #split.
    The name "to_parts" is not appropriate.

      % ruby -rbigdecimal -e 'p BigDecimal.new("12.34").to_parts'
      [1, "123400", 10, 2]

  -> Accepted.

  * renaming/removing BigDecimal#assign

  -> Accepted (removed).

  * requiring rational.rb and bigdecimal-rational.rb in bigdecimal.
    Otherwise users must write:

      require 'bigdecimal'
      require 'rational'
      require 'bigdecimal-rational'   # BigDecimal<->Rational conversion utility

  -> Rejected.  Converting BigDecimal and Rational is rare case.
     Also, bigdecimal-rational.rb/bigdecimal-math.rb are just for samples.

  * BigDecimal#E/#PI are methods, so their names should be in lower case.

  -> Rejected.  They are mathematic constants.
     Also, Shigeo Kobyashi noted that he is thinking
     to remove these methods (see below).

  * removing BigDecimal#dup because BigDecimal is not a mutable object.
    FYI: BigDecimals were mutable in the past.

  -> Accepted.

  * adding new method String#to_d
  * adding new method Kernel#BigDecimal(str)

  -> Rejected but add these methods in bigdecimal-misc.rb or so.

  * renaming bigdecimal-*.rb to bigdecimal/*.rb.

  -> Accepted.

[ruby-dev:20491] [Oniguruma] explicit capture
[ruby-dev:20514] [Oniguruma] Version 1.9.1
(contd.)

  K.Kosako and TANAKA Akira proposed Oniguruma's semantics about
  named/numbered capture.  FYI, "named/numbered capture" means

    named capture:     p /(?<tag>aa)/.match("xaax")['tag']  #=> "aa"
    numbered capture:  p /(aa)/.match("xaax")[1]            #=> "aa"

  Summary of the proposal:

    1. Keeps all backward compatibility if we do not use named capture.

    2. If we use named capture, (...) works as (?:...).
       We cannot use named capture and numbered capture in one regexp.

       m = /xx(?<n>aaa)xxx/.match('xxxaaaxxx')
       p m['n']   #=> "aaa"

       /xx(?<n>aaa)xx(x)/    # maybe RegexpError

    3. If we use named capture with "c" option, (...) works as numbered
       capture.  We can use named and numbered capture in one regexp.

       m = /xxx(?<n>aaa)xx(x)/c.match('xxxaaaxxx')
       p m['n']   #=> "aaa"
       p m[1]     #=> "x"

    4. If "C" option used, (...) works as (?:...).

       m = /xxx(aaa)xxx/C.match('xxxaaaxxx')
       p m[1]   #=> nil

  Reasons:

    1. Users may not use named and numbered capture at the same time.
       If this is true, we does not need c/C options so much.

    2. (?:...) is too long.  Mixing (?:...) with (?<n>...) makes matter
       even worse.

  Note that "c" is the temporal one.  Matz suggested "g" for the
  same sake.

[ruby-dev:20570] Marshal upgrade
[ruby-talk:75439] Re: Marshaling objects partially

  Matz noted that he is thinking to update the minor version of marshal
  format in 1.8.0.

[ruby-dev:20580] add library
[ruby-talk:75961] Re: [Ann] OSSL 0.2.0-pre3

  TAMURA Ken'ichi proposed making WEBrick a standard library.
    * WEBrick: http://raa.ruby-lang.org/list.rhtml?name=webrick

  Matz proposed bundling OSSL2 as a standard library, and this thread
  is continued to [ruby-talk:75961].
    * OSSL2: http://raa.ruby-lang.org/list.rhtml?name=openssl

  Matz also proposed bundling SOAP4R, but NAKAMURA Hiroshi, the author
  of SOAP4R, said that dead line is too close.
    * SORP4R: http://raa.ruby-lang.org/list.rhtml?name=soap4r

[ruby-dev:20655] frozen ThreadGroup

  Current implementation of ThreadGroup#freeze prohibits modifying
  thread group members on only $SAFE>4.  Hidetoshi NAGAI proposed
  to change this feature, to prohibits modifying members *always*.
  He needs this function for implementing safeTk package.

  Matz took his intention into account, pointed out that the method name
  "freeze" is not appropriate because we can add new threads to a frozen
  ThreadGroup, by forking child threads from its member threads.

  Then, here's the new scheme to limit functions of ThreadGroup:

    * ThreadGroup#enclose
      disallows adding/removing threads to/from ThreadGroup.

    * ThreadGroup#freeze
      disallows modifying thread group members.
      (disallow creating new child threads of members)
      disallows defining new (singleton) methods to ThreadGroup, etc.
      (normal "freeze" semantics)

[ruby-dev:20703] MatchData#groups

  TANAKA Akira suggested to rename MatchData#groups to #captures,
  because not of all groups are captured in Ruby.  e.g.

    /xxx(?:This is a group but not captured)xxx/


[ruby-dev:20680] 1.8.0 on IA64 etc.

  It is known that ruby 1.8.0 preview3 "make test" crashes on IA64,
  x86-64, and PPC64 platforms.  Matz is calling for testers/debuggers
  before releasing forthcoming 1.8.0.

[ruby-dev:20690] portable(?) UserID/GroupID control
[ruby-talk:76218] portable(?) UserID/GroupID control

  Hidetoshi NAGAI proposed highly portable APIs to control uid/gid.
  He also provided a patch for CVS main trunk in these messages.


-- Minero Aoki