I was talking to Sunil tonight at PSDN Live 08 about some of the OEA performance issues that have been reported on this forum and it turns out that there were some "intelligent parsing" mods that didn't make it into beta, but which are "likely" to make it into FCS ... of course, no one can ever promise anything! But, basically, this does things like not parsing an include until one make a change which might impact the include, so, much of the time, the initial load of any module should be fast and if you make your changes to IPs and such, that should be quickly updated as well. Of course, if you update the main procedure, it may have to syntax check the whole mess and then you will have to pay the penalty for you 1000 line includes or includes nested 16 deep. But, hey, Julian, you are way off the hook ... someone here told me about an app whose startup procedure is in the neighborhood of 380,000 lines, once one counts all the includes. I don't think any comment is necessary.
In fact, I have suggested twice today that the right thing to do in terms of handling some of this kind of thing in tools was to say, "You shouldn't be doing this, so don't complain to me that it doesn't work like other parts of the product".
In fact, I have suggested twice today that the right
thing to do in terms of handling some of this kind of
thing in tools was to say, "You shouldn't be doing
this, so don't complain to me that it doesn't work
like other parts of the product".
That will keep people away from migrating to the Advanged GUI. Maintenance of existing applications will pay the bills while most developers may get started with learning and potentially adopting the Advanced GUI in OpenEdge Architect. And it's a matter of fact that you can't use the Advanced GUI without OEA (except those using my Dynamics rendering engine ).
Maintenance of the existing apps is a matter of survival. People I've spoken to would rather stick with the AppBuilder to be able to react to user/customers requests and bug reports as quick as the can than try the fancy new stuff and loose the ability to continue to work on the existing apps.
If you suggest that Progress should not take care of the (issueless) ability to work on any old - grown code in OEA, then it should come along with the suggestion that unlimited usage of both tools should not just only be an option for PSDN subscribers. Basically that should come along with the request to only have one dev license for both tools.
If you suggest that Progress should not take care of
the (issueless) ability to work on any old - grown
code in OEA, then it should come along with the
suggestion that unlimited usage of both tools should
not just only be an option for PSDN subscribers.
Basically that should come along with the request to
only have one dev license for both tools.
Indeed, that or allow to get OE Studio for the price of the VSLICK OCX license if you already have the OEA license, that should keep everybody happy.
I think we may not be thinking quite the same thing, but let me just clarify a bit. In one of the conversations I was having yesterday, it was suggested to Sunil that he simply draw a line in the sand and say that, if one wanted to use OEA, then one had to accept certain limitations, e.g., no preprocessors. Sunil was very clear that while that was tempting, it was not acceptable; one needed to be able to handle any code, even if everyone agreed it was bad code because that code was the the real code that was out there. However, which said, one also had to recognize that bad code might present certain limitations of performance or behavior. If one loads 380,000 lines of code, one has to figure that it will take a while to parse. If one has preprocessors, e.g., his example of using a preprocessor as a part of a class name!, then one should recognize that this is going to present certain obstacles to the parser.