Re: using ruby reflection to generate code

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.

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...  :-)

doug

-- 
"Contrary to what most people say, the most dangerous animal in the
world is not the lion or the tiger or even the elephant.  It's a shark
riding on an elephant's back, just trampling and eating everything they
see." -- Jack Handey