From: ahoward <ahoward@...>
Date: 2002-11-11T00:04:24+09:00
Subject: Re: return MyClass.new vs self.type.send :new

On Sun, 10 Nov 2002, Brian Candler wrote:

[snip]
> Another objection centres around the arity and semantics of constructors.
[snip]

i didn't have the stomach to also address that issue... quite a post! ;-)

one verbose way around the arity problem is to always use a

  def method (*args)
  end

or

  def method (keywords)
  end

signatures, where args.type -> Array and keywords.type -> Hash

at least this allows

  class Parent
    def method(keywords)
      @pvar = keywords['pvar']
    end
  end

  class Child
    def method(keywords)
      super
      @cvar = keywords['cvar']
    end
  end

and arity is never an issue...  just a thought.

[snip]
> You can't just create an instance of the base class using the base class's
> constructor and just 'flip' the type to be SubClass; that would leave the
> subclass's extra instance variables uninitialised, potentially giving you an
> invalid object instance.
[snip]

you *can* if you design it that way :

  module ParentMethods
    def ParentMethods.extend_object anObject
      ...
      do_the_right_thing    # tricky
      ...
    end
    ...
    ...
    ...
  end

  class Parent
    include ParentMethods

    def Parent.bless anObject
      ParentMethods.extend_object anObject.clone
    end
  end

  object_as_parent = Parent.bless object

i've been using a this design pattern in my work.  i've found that separating
out methods into modules, exclusively, has been very flexible for this, and
other, reasons.

-a

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================