Class Definition inside a method definition?

Ruby
21

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?

+1

Gary W.

22

Logan C. 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

23

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

24

Pit C. 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!
:smiley:

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.

25

On 4/12/06, Bihal [email protected] 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.

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