From: Kazuo Saito <ksaito@...>
Date: 2003-10-15T21:07:15+09:00
Subject: ruby-dev summary 21531-21607

Hello all,

This is a summary of ruby-dev mailing list.


[ruby-dev:21531] O_ACCMODE

 Tanaka Akira added a constant Fcntl::O_ACCMODE defined
 in POSIX fcntl.h to ext/fcntl module.


[ruby-dev:21538] rb_frame_last_func for alias method

 In the method called with an alias name, rb_frame_last_func()
 returns an ID of the alias name in 1.8.0 release.  In 1.6.0,
 it returns an ID of the original name.

 Kazuhiro Yoshida asked how to get original name ID.
 Matz recommended to include "env.h" and get the ID from
 ruby_frame->orig_func.


[ruby-dev:21543] Enumerator
 (Thanks knu for writing this summary)

 Akinori MUSHA asks again if there is any objection to
 adding Enumerator to the standard distribution, which was
 once nominated before the 1.8.0 release.  None is raised.

 Koji Arai suggests adding more libraries from the "rough"
 module so people start to try them out.

 They discuss the issue on and agree that it would be fine
 to include and develop new libraries in the development 
 branch of ruby, because the main ruby module is much more
 exposed, popular and appealing than the "rough" module.
 The branch is meant to be the best test bed.

 MUSHA, on the other hand, notes that once a new library is
 added to a stable version of ruby, developers must be 
 careful not to break backward compatibility on that branch
 and they should keep distributing it stand-alone for users
 that use old releases.

 He also points out that in order to make the "rough" module
 work better as a farm for (really) rough rubies, we should
 try to get people to know about it and provide a handy 
 installer to make it easier for them to try it out.


[ruby-dev:21590] extend with marshal_dump/marshal_load

 Note:
 Currently, these method's implementation is being heavily
 changed. Check the source first if you try to use them.
 It may be different from our summary.


 NAKAMURA, Hiroshi and Matz is talking about keeping 'extend'
 information of marshaled object.  It is dumped by default,
 but when each user defines his/her original marshal_dump
 and marshal_load, the default behavior is ignored so s/he
 is responsible for supporting the information by themselves.

 Matz showed us in [ruby-dev:21593] an example how to dump
 and load such objects correctly.  In following example, 
 objects of class Quux can be dumped and loaded.  Note that
 class Foo and Bar does not needed to concern about 
 marshaling 'extend' information.

 This example is already applied some patches by NaHi in
 [ruby-dev:21595] to original one:

----
class Foo
  def initialize
    @data_a = 1
    @r, @w = IO.pipe
  end
  def marshal_dump
    @data_a
  end
  def marshal_load(obj)
    @data_a = obj
    @r, @w = IO.pipe
  end
end

class Bar < Foo
  def initialize
    super
    @data_b = 2
  end
  def marshal_dump
    [super, @data_b]
  end
  def marshal_load(data)
    super(data[0])
    @data_b = data[1]
  end
end

module ExtendMarshal
  def marshal_dump
    base_data = super
    extends = (class << self; self; end).ancestors - self.class.ancestors - 
[ExtendMarshal]
    data = {:modules => extends, :base => base_data}
    extends.each do |m|
      m.instance_method(:marshal_dump_extend).bind(self).call(data)
    end
    data
  end
  def marshal_load(data)
    extends = data[:modules]
    extends.reverse_each do |m|
      self.extend(m)
      m.instance_method(:marshal_load_extend).bind(self).call(data)
    end
    super(data[:base])
  end
end

module Baz
  include ExtendMarshal
  def marshal_dump_extend(data)
    data[:Baz] = 42
  end
  def marshal_load_extend(data)
    @baz_data = data[:Baz]
  end
end

class Quux<Bar
  include ExtendMarshal
end
o1 = Quux.new
o1.extend(Baz)
o2 = Marshal.load(Marshal.dump(o1))
p o1
p o2

----

Kazuo Saito <ksaito@uranus.dti.ne.jp>