Can't you use Ruby's C API to do all this? Why are you "reverse-engineering" ruby especially given ruby's open source nature.
On Apr 11, 2006, at 7:27 PM, Bihal wrote:
e have an in-house parser already, which we provide grammar files to so
that it can parse. Because it's modelling software, it's not simply a
matter of parsing it, but telling the software what to do with each line
when reverse engineering.
+1
Gary Wright
On Apr 11, 2006, at 10:40 AM, Rolly Ferolino wrote:
I don't think that the original question was annoying. It came from someone
new to the language and sincerely wanted to learn it. Not all of us are
experts in parsers and semantics; and some of us need additional dialogue to
get the concept sink in. What's annoying to others might be interesting to
some. So what's the use of the community if it is not willing to help?
Logan Capaldo wrote:
Can't you use Ruby's C API to do all this? Why are you "reverse-
engineering" ruby especially given ruby's open source nature.
Because the aim is to parse and produce a (design) model from the code.
Not a list of source files (like in an IDE), but diagrams that show
relationships between classes, etc.
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.
I hope that makes sense.
Bihal
--
Posted via http://www.ruby-forum.com/\.
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
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 can1) 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!
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/\.
For the static part of the modeling, you may want to try to understand
how RDoc generates DOT files for generation with AT&T's GraphViz,
since it can at least do basic class diagrams.
-austin
On 4/12/06, Bihal <wmioch@hotmail.com> wrote:
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.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca