Pit Capitain wrote:
> Bihal schrieb:
>> Our software has support for round-trip engineering, which means forward 
>> and reverse engineering and code synchronisation. Which means you can
>> 
>> 1) Import your code and see how it works from a high level
>> 2) Design your code and generate the source files from the design
>> 3) Import code or create a design, and synchronise changes forward and 
>> backward. ie. Change the code and the model can be updated, change the 
>> model and the code can be updated.
> 
> Bihal, forward engineering Ruby code should be no problem, but I doubt
> that you can reverse engineer arbitrary Ruby code. I see at least the
> following problems:
> 
> 1) The Ruby object model is different from that of other OO languages.
> In Ruby, you can add methods to single objects. I don't think that the
> meta model of your tool can represent this concept. You would also need
> to handle Ruby's concept of mixins, which is a kind of multiple
> inheritance, but with slightly different semantics.
> 
> 2) Ruby is very dynamic. You can create and alter classes and methods at
> runtime. The design model of such code could only be determined by
> actually running the code, and it could be dependent on runtime 
> parameters.
> 
> 3) You can use method_missing to implement methods "on the fly". A tool
> has no chance to recognize those methods. Even running the code wouldn't
> help in this case.
> 
> Again, it would be nice to have Ruby support in your tool, but there are
> huge problems way beyond the syntax level. As others have mentioned, I'd
> strongly suggest learning the Ruby concepts first. Only then, if you
> still think your tool can handle all this, should you look at the 
> syntax.
> 
> Regards,
> Pit

Thanks Pit.

Yes, as I've come to know Ruby better, I've run into these things. Some 
have already come up in other languages, but Ruby is pretty unique. 
However, we can only start with the basics, and that's all we're aiming 
for at the moment.

How to model the more complicated parts (and mix-ins is one we've 
already discussed) are really being pushed into the "later" box for the 
time being. Our tool is quite customisable and I do believe we could 
accomodate most of Ruby's nuances.

I'm kind of hoping that in the future when we are figuring/deciding 
these things, that some of you guys might be able to provide some input! 
:D

Bill

PS: I don't know if this is implicit or not, but in our software code 
that is just parsed as general code is left alone in the synchronising, 
so mixins etc. would not be damaged by reverse engineering, just 
not...conceptualised.

-- 
Posted via http://www.ruby-forum.com/.