D
David Abdala
Guest
I agree that documentation of BIND and BY-REFERENCE is very confuse, and it takes some time, and pain, to get to do with it what you actually want. We use it extensively for NSRA framework, where DAO classes are subdivided in Main, and Subordinate classes. Main DAO classes define a PRODATASET and a set of "regular" TT to hold a full DataEntity, whereas a DataEntity is a Bussines "whole" concept, like an "Invoice DataEntity" which is all the information relevant to an invoice in the bussines language: Head, Detail Lines, Customer, Shipment, Receipts, etc. Each DataEntity is hold by only one DAO class, which is responsible only for the "main" TT of the data structure. For each other TT of the DataEntity a Subordinate DAO is instantiated, and BINDed to the TT which this instance is responsible for. Each TT is defined in an include file, with an "optional" BY-REFERENCE, so TTs are included in the Main DAO class as regular TT, and in the Subordinate DAO class as BY-REFERENCE. Subordinate DAO classes BIND to the TT in the constructor, so the data is available throughout the lifecycle of the object. The lifecycle of Subordinate DAO objects is under Main DAO object control, so there is no way of having an "unbounded" BY-REFERENCE TT in a Subordinate DAO object. As only one object operates on every TT, there is no DEFAULT-BUFFER conflict, besides "regular" conflicts, unrelated to BIND and BY-REFERENCE. We don't use it anywhere else, as others stated, it is a "dangerous" functionality, as only explodes at runtime, and in very difficult to debug ways. Most of the use of BIND and BY-REFERENCE is due to the fact that "you" (read Progress) never implemented trueTT objects, from which you can INHERIT. I'm been waiting for this since 2009... luckily I'm sitting most of the time...
Continue reading...
Continue reading...