"Richard Kilmer" <rich / infoether.com> wrote
> That is powerful...but not what I am talking about.
>
> Here is a simple example:
>
> class Foo
>    def intialize(x,y,z)
>
> # at this point I press a magic generator key and this code appears:
>
>      @x = x
>      @y = y
>      @z = z
>
> # and then displays a dialog to chose which of these you want
> externalized
> # (if any) and inserts (above def initialize...) something like..
>
>     attr_accessor :x,:y
>     attr_reader :z

Rather than use editor magic, why not just define an "initializer" function
on Class?

class Class
  def initializer (attributes, externalized_attributes)
      module_eval <<-END
      # here generate code such as
      # attr_accessor ...
      # attr_reader ...
      # def initialize ...
      # etc.
    END
  end
end

class A
  initializer ([:x, :y, :z], [:x, :y])
end

That way the visible and maintained code for class A remains uncluttered and
declarative. The way the code generator "implements" the initializer
construct can change without impacting class A's definition. If you really
wanted to, def initializer could even display your dialog e.g. if the
'externalized_attributes' argument was missing, but that seems like
inappropriate mixing.

Refactorings basically change some detailed code structure while preserving
some abstract properties (relatively speaking). I thought at first that you
were suggesting something like this as a way to write relatively abstract
Ruby that was less sensitive to refactorings.

Cheers ...