From: Wyss Clemens <WYS@...>
Date: 2001-05-07T23:42:01+09:00
Subject: [ruby-talk:14770] RE:  SimpleDelegator assymetry

The Ruby "delegate" implementation takes the object from the constructor
(the super-call) to find out the API which is to be implemented (i.e. to be
delegated). These methods are then dynamically "added" to the
Delegator-class (i.e. ANB).
In your third example, it is the NilClass!
__setobj__ has no influence on the Delegator-API.

To be PoLS or not to be PoLS ;-)
Regards
Clemens
-----Urspr�ngliche Nachricht-----
Von: Robert Feldt [mailto:feldt@ce.chalmers.se]
Gesendet am: Montag, 7. Mai 2001 16:20
An: ruby-talk@ruby-lang.org; Ruby talk mailing list
Betreff: [ruby-talk:14768] SimpleDelegator assymetry

Hi folks,

Can someone explain the "assymetry" in the behavior of the code below?

/Robert

require 'delegate'
class STB1; def b; 1; end; end
class STB2; def b; 2; end; end
class ANB < SimpleDelegator
  def initialize(o)
    super(o)
  end
  def change(o)
    __setobj__(o)
  end
end

def test(first, second)
  a1 = ANB.new(first)
  begin
    puts a1.b
  rescue NameError
    puts "1: Caught error"
  end
  a1.change(second)
  begin
    puts a1.b
  rescue NameError
    puts "2: Caught error"
  end
end

test(STB1.new, STB2.new) # Both ok.
test(STB1.new, nil)      # Ok, error on 2nd call since nil has no b method
test(nil, STB2.new)      # but why error on 2nd call here? 
                         # Or is it just my PoLS feeling that is wrong?
                         # Ps. PoLS = Principle of Least Surprise