From: ptkwt@...1.aracnet.com (Phil Tomson) Date: 2003-04-16T03:46:40+09:00 Subject: Re: using ruby reflection to generate code In article <20030415132450.A49913@beaver.net>, Doug Beaver wrote: >On Tue, Apr 15, 2003 at 01:02:05PM +0900, Phil Tomson wrote: >> In article <20030414212552.A46129@beaver.net>, >> Doug Beaver 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