Reflection - Parsing a class

My understanding is Java and it reads the rcode. I know that OEUnit (testing tool) uses xml-xref. I have an idea that ABHack has similar functionality and it's all ABL.

Are you providing ABL editing capabilities inside your app?

-- peter

I looked at the xml-xref, but it seems kinda weird - the reference to

methods point to the line of the "END METHOD"

Don't suppose that the r-code java reader is available for other

usage, is it ? Or is the r-code structure documented somewhere ?

No, not providing and editor, but I am building code generators and I

want to be able to read classes back in and maintain custom methods

and properties so that the code is not lost.

I know that the good Doctor and I have had lots of discussions about this

I currently use annotations but I know that you don't like this

Don't suppose that the r-code java reader is available for other

usage, is it ? Or is the r-code structure documented somewhere ?

No, I don't believe so, for both cases. Although certainly the stuff you're interested in in this case falls under the rubric of reflection and thus would, I guess, be addressed in that way.

No, not providing and editor, but I am building code generators and I

want to be able to read classes back in and maintain custom methods

and properties so that the code is not lost.

I currently use annotations but I know that you don't like this

Oof. Ouch.

I'm not globally opposed to annotations, but in this case I still think that the custom stuff should be in a derived class.

-- peter

Hint:  The piece of OEA that provides the information for syntax coloring, hints, the outline, etc. is doing exactly the same job done by Proparse.

But, it is a good opportunity for me to plug http://www.cintegrity.com/content/Model-Code-ABL

hah. When I suggested that, I was shot down

One of the other problems is that I want to allow some custom code

inside the generated methods, to cater for the odd circumstance where

a generic generator does not provide all the code required. Yes, yes,

I know. One day the generator will provide all code. But, one day the

sun will also die ..

Understand, Peter, that what Julian is trying to do is *not* a standard base class and then some variations ... where a derived class or delegation or something would be the right answer.  Instead, what he has is hundreds of classes which follow the same basic template ... but where there is a need for instance to instance variation to some degree.  Rather than doing what I want him to do, i.e., get those variations into the model and generate from that, Julian wants to generate the standard form, do some manual modifications, and then in essence "reverse engineer" those into the next generation cycle ... except, since he has no model, there is nowhere to parse and place the modifications and he thus has to do it on the fly in the next generation cycle.

meh. After all the time you, I, John and Jurjen put into "playing"

with the oo-proparse (http://www.oehive.org/node/1250) how could have

I forgotten that one ! Doh!

Thanks

On 1 April 2011 18:44, Thomas Mercer-Hursh

and one of the reasons that I'm not doing what you want is that I need

to get code out there tomorrow, not next year

Dr Mercer-Hursh shudders

On 1 April 2011 19:01, Thomas Mercer-Hursh

jmls wrote:
meh. After all the time you, I, John and Jurjen put into "playing"
with the oo-proparse (http://www.oehive.org/node/1250) how could have
I forgotten that one ! Doh!
Thanks
On 1 April 2011 18:44, Thomas Mercer-Hursh

We use AutoDox2 for the new AutoEdge stuff, which is based on ProParse (and it works like a charm), and I saw an extension to AutoDox on the OEHive which writes XML, which may make your life easier.

-- peter

Understood ... as long as you aspire to better yourself in the future!

jmls wrote:
hah. When I suggested that, I was shot down 
One of the other problems is that I want to allow some custom code
inside the generated methods, to cater for the odd circumstance where
a generic generator does not provide all the code required. Yes, yes,
I know. One day the generator will provide all code. But, one day the
sun will also die ..

There are ways around this (abstract methods, events, callbacks etc), but I remember now that you wanted a single type per object (ie no hierarchy).

How much customisation do you expect there to be to the generated code?

-- peter

I think all those approaches are making something far more complicated than it needs to be ... and, worse yet, they are making the actual run time code complicated when the problem is really one of generation.  One can make an argument in some cases for programming an entirely generic class instead, but again this requires a massively complex run-time compared to what one would have if one could just tailor the generator.  In comparable efforts (going back to 1990), I was looking to get about 90% of the code out of the generator and only have to manually supply the stuff that was unique to an instance.  Julian is using a somewhat simpler approach than my old Specification-Driven Development tool so he probably can't aim that high, but could do fine for simple cases ... which is all I think he is trying to tackle at this point.

I want to be able to have the flexibility to add code where the

generator does not provide such circumstances, until the time that I

can modify the generator to cater for such things.

For example, one of my "crud" classes needs to delete an operating

system file when the object is destroyed, so I need to have a custom

destructor. I can create a super-class that contains a destructor

override, or I can type in the code into the destructor of the class

in question. At some stage if I find the time, I will then build

that special case into the generator by adding another property to the

generation options of that class

that's twice this year we've agreed on something

On 1 April 2011 19:38, Thomas Mercer-Hursh

I'm sure the date is significant!

This is done with ANTLR, you can actually use the same classes used by OE Architect (it requires a bit of work but I am 100% sure it can be done ;-) ). You may even be able to use them from ABL with ikvm. The advantage of the OE Architect ANTLR parser over the proparse.NET ANTLR parser is that it works to some extent even for sources that don't compile (yet).

The advantage of the proparse parser is that it provides a documented API and more information (and you're not doing something that you're not supposed to do and may not be able to do in the future.)

Interesting. Thanks.