S
slacroixak
Guest
Re #1 I am wondering if we are talking about the same case. In my tests, hmyProc:INSTANTIATING-PROCEDURE is always unknown if myProc.p was run from an ABL class. Do you really manage to obtain something else in instantiating-procedure in such a case? Yes, a parentProc that launches some childProc is not always responsible of destroying it. But a ChildProc can be launched by many different possible parents, so it does help to find out who has launched it, especially when you find many instances (say tens or hundreds) of a procedure, and top of all when they are launched by some RUN VALUE. Re #7 "Also, this is not information that is available in most programming languages (none that I know of). Therefore, it seems suspect that it should be necessary." => Other programing languages do not offer elementary constructs like a record buffer or an embedded database engine in the client side to handle temp-tables. And we see its value The ABL is a double facet language. When using only .p’s we are in the script world with surprises at run time. We *progressively* move to OO with more check at compile time and less surprises at runtime. In the few (very few) cases that do require a DYNAMIC-NEW(), I can enforce a best practice to always pass the caller object class reference (or the caller procedure handle) to the constructor of the called class so I can find out who has called it later (with interfaces, I can easily make sure I have not missed a case). On the other hand, it is much harder (even impossible) to refactor all the guys that can possibly called by some RUN VALUE because there is just no way to identify them. Hence the RunTime tools I need to be efficient: just gather some logs and fix the problems as they get reported, instead of playing with crystal balls or sophisticated tools that may always miss a point. What is at stake is the “progressively” said above. ABL developers are expensive. If Progress wants to help its customer to survive long and well, then perhaps it is worth doing a few constructs that do not exist in other languages. I could find other related ideas. In the same area, I believe Progress did a good job to introduce the new error handling with CATCH/THROW etc… so it can be adopted progressively. At first people did not dare to enable SESSION:ERROR-STACK-TRACE because of its possible impact on performance. Now we always enable it to get stack traces because the extra CPU resources are worth the efficiency when we investigate an issue. Perhaps I should enter an ER to have the ability to trace a caller like I said in point #6.
Continue reading...
Continue reading...