Re: using ruby reflection to generate code

In article <[e-mail]>,
Doug Beaver  <[e-mail]> wrote:
>On Tue, Apr 15, 2003 at 01:02:05PM +0900, Phil Tomson wrote:
>> In article <[e-mail]>,
>> Doug Beaver  <[e-mail]> wrote:
>>
>> > 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 agree that objc requires fewer hints, but there's still some stuff i
>can't look up just by using reflection.  for instance, i can use
>Method#arity to see how many args my methods take, but i don't know what
>the names of the args are.  objc's methods are smalltalky, so i end up
>doing this, ignoring the types completely and autogenerating the
>selectors:
>
>- (id)meth:(id)val1 arg2:(id)val2 arg3:(id)val3;
>
>i thought i could set defaults for the args in the definition, but then
>arity doesn't work.  i remember seeing threads on ruby-talk saying that
>this is by design, so i'm trying to figure out other ways to look at
>method args.
>
>def meth(arg1, arg) -> arity returns 2
>def meth(arg1=0, arg2=[]) -> arity returns -1
>
>i think with hints, i can at least get the args named and typed
>correctly, and just make all the methods return id.  or maybe force
>myself to declare a return type with a hint, and then overload return to
>raise an exception if i attempt to return a value from the method that
>doesn't match that type:
>
>def meth(stack = [])
>  args :stack,  Array
>  return_type Float
>  # do some stuff
>  return false # throw InvalidReturnTypeException
>end
>
>i'm thinking now that i'm going to try to get something working with
>hints, and if i get usable code out of it, then i'll try to hook in
>NodeDump or something similar so i don't have to use hints at all.
>ideally, you would write a bunch of code, load all the classes into the
>translation module, and then it would DTRT and generate your objc for
>you with no hassles.
>
>brian candler suggested that i turn the hints into assert calls, which
>would be checked at runtime in ruby and compile time in static
>languages.  that sounds really interesting, i might do that instead.  i
>love the idea of using assertions for that sort of thing.
>
>i also noticed after searching for c++ generation on ruby-talk, that bob
>calco was working on a framework called RuGen that would let you design
>in ruby and generate different output languages.  that looks cool!
>
>> > 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.
>
>this sounds very interesting, i didn't think of involving swig.  i
>wouldn't be creating that many new c++ classes, just using different
>frameworks we already have for creating services, but i think it still
>works well.  it sounds like that with this method, i'd still have to
>check in ruby code for the unit tests, which won't work for me.  i think
>i could come up with something where i have the ruby tests on my
>desktop, create a set of c++ unit tests that attempt to test the same
>things, and then run them side by side until i get the same results,
>checking in the c++ tests when i'm satisfied.

What do you use for C++ unit testing now?  I remember trying cppunit and 
not being able to get it to work which led to using swig and 
Ruby/Test::Unit (which in turn led to other benefits like being able to 
script our app in Ruby). 

>
>it makes me feel a little uneasy, though.  i wish i could just check
>ruby code in.  i evangelize ruby at work, but we have hundreds of
>developers, and the company has paid for many of them to be trained in
>perl, so it's a bit of an uphill battle.  i think i can find a niche for
>ruby in code generation and developer tools, but first i have to build a
>community of people who are reasonably fluent in ruby so that we can
>review each other's code.  nothing like the little details...  :-)

Sounds like you'll need to find some allies.  If you can demonstrate 
productivity gains with your approach to prototyping in Ruby and then 
translating to ObjC/C++ then that could be a win.

Phil