D
dbeavon
Guest
>> Just pass in the same TT again. If you want the data to be there all the time once the call is made, then the data needs to be copied. That makes it "sticky"! It was the first time I had ever encountered a scenario where a static TT stopped referencing something which had previously been referenced. I suppose the upshot is that it makes our business classes slightly more reusable - if you can rebind their static references again to some totally different TT. But that doesn't come up very often, and I would typically just create a new instance of a logic-class if/when I need to provide it with a different instance of a TT. Its odd that the runtime is able to unbind the static TT when the method returns. As far as I know there is no way for a programmer to do that ourselves. If the runtime can do it then you would think ABL language would have a statement to do the same thing. Another "sticky" approach would be to use BIND. For example if I have two logic-class instances A and B. Both have reference-only data. And instance A creates the logic-class B and wants to pass it a shared static dataset then it can transfer the reference permanently via a BIND parameter (rather than simply trying to pass it in with the "BY-REFERENCE" keyword). The references all point to the same underlying data, and the references will remain in place for as long as the logic-class exists. The BIND approach is more permanent. But conceptually I would have expected them to behave in a similar way. It does not feel right for the runtime to take away a dataset that had been referenced by class's member. Its like a rug getting pulled out from under your feat. By the time it is taken away, the dataset reference has become an integral member of the class, and may have been used from the context of *numerous* private methods (without necessarily passing it around as a parameter). Things would be less confusing if there were a way to scope the static dataset declaration to a *single* method, rather than to the class as a whole. Then it would be very clear why the dataset reference is lost after the method returns. I think the current behavior tries to pretend that the data wasn't actually adopted as a member of the class for a period of time.
Continue reading...
Continue reading...