From: ptkwt@...1.aracnet.com (Phil Tomson)
Date: 2003-04-15T13:02:05+09:00
Subject: Re: using ruby reflection to generate code

In article <20030414212552.A46129@beaver.net>,
Doug Beaver  <doug@beaver.net> wrote:
>On Mon, Apr 14, 2003 at 02:55:07AM +0900, Phil Tomson wrote:
>> In article <20030413004111.A80880@beaver.net>,
>> 
>> I'm not currently doing this, but I do kind of want to be able to
>> convert RHDL to VHDL and/or Verilog which would entail some similar
>> effort (actually, it would probalby be harder).
>> 
>> At any rate, I really would be interested in seeing your code to
>> generate objective C and/or C++, can you post this or submit it to the
>> RAA?
>
>here is a first version, i put some comments at the top to discuss its
>limitations:
>
>http://beaver.net/ruby/objc_render.rb

Thanks for sharing.

>
>phil and i talked over private email about DumpNode, it looks promising,
>at least for figuring out names and types of method arguments, maybe
>even the return type.  i also thought it might be possible to put
>attr-like hints in the ruby code, so you could do:
>
>class Song
>  def play(track=0, duration=0)
>    args :track, Fixnum, :duration, Fixnum
>    retval :didPlay
>
>    # try to play the track here, set didPlay to false if it didn't work
>    return didPlay
>  end
>end


>
>i think you have to end up using some sort of hint in your ruby code,
>ruby is too dynamic.  

True.  I've had similar thoughts for RHDL-> VHDL conversion.

However, Ruby being dynamic and ObjC being dynamic probably means that 
Ruby->ObjC would be a lot easier and would require fewer (if any?) hints, 
no?

>i'm attempting this because i'm trying to develop
>a secret weapon, i want to use ruby to prototype designs and generate
>boilerplate code for use at work.  we have a large perl and c++ base,
>and it will be quite a while (i think) until ruby is accepted at work,
>but i'd still like to use it to help me write code there, if i can.
>the objc rendering code is the first shot just because i've been writing
>a lot of cocoa code lately and figured objc was closer to ruby than c++.
>
>i might end up writing a ruby extension for the c++ frameworks we use
>and then use ruby to glue things together, skipping the boilerplate
>generation altogether.  once i had a working product, i would then rip
>out the ruby code (whose design had been well tested at this point) and
>replace it with handwritten c++ code when it's time to ship.  i'm hoping
>that having lots of good unit tests will cut down on errors when i port
>the glue from ruby to c++.  i'm interested to hear if anyone else is
>doing something similar to this...

Swig would probably be good for this.  You could use it to develop 
your C++ classes in both C++ and Ruby; sort of rapid prototyping where you 
minimally define your class on the C++ side but then you fill in methods 
on the Ruby side.  As you figure out exactly what you want your class to 
do  and you have a good idea that things are working the way you 
want, you can define these methods on the C++ side (and continue 
iteratively until you've defined all the methods in C++ if that's your 
goal).  As a side benefit you'll be able to unit test your C++ code using 
Ruby and Test::Unit.  Your unit tests would be defined in Ruby and as you 
move Ruby code to the C++ side the same tests can be used to ensure that 
things still work the way they did in Ruby.

Phil