D
dbeavon
Guest
If I use the word "static" below it is in relation to statically defined data; I'm not talking about static membership of a class. BIND has more explicit declaration requirements. My understanding is that it has to be used from both the caller and callee. Whereas passing something "BY-REFERENCE" can be done as an afterthought and different clients of a given program can either use that convention or not. I suspect that whenever you send BY-REFERENCE data to program, then the runtime for that program will simply dispose of the instance of the static data that it would have otherwise used. BY-REFERENCE seems to be a more flexible and more easily approached mechanism for static data that is being passed for INPUT arguments and INPUT-OUTPUT . The only time that a client program absolutely MUST designate that an argument is BY-REFERENCE is if the called program has declared the data to be "REFERENCE-ONLY". But you probably won't know that is the case until run-time. On that note, most of the complaint I have with this stuff is that the compiler doesn't help matters much, and leaves you in suspense until you test out your code at run-time. But this complaint is not isolated to this topic. Thankfully the OO side of ABL provides much better compile-time assistance. There are some very *unusual* gotchas that arise when using BY-REFERENCE data and sending it into an OO class where the member data is declared REFERENCE-ONLY (as we normally do in our business logic layer). The member data in the OO class will now become a reference to the original instance of data that was passed in. If you then call some other instance methods of the class, the reference will remain in place. But when the flow-of-control finally *exits* from the original method (the one that received the BY-REFERENCE data) then the OO class will somehow "un-reference" that static data. Any subsequent call to the class will fail if it tries to access the same REFERENCE-ONLY member data (without supplying it once again as a parameter). This behavior seemed fairly strange when I first encountered it, especially since ABL does *not* seem to provide any "un-reference" or "un-bind" operation for programmers to use ourselves. It is also unnerving to have class instance with a reference to a dataset one moment, and then on a subsequent call to the same OO class, you find that the dataset has vanished, simply because of the flow-of-control (unwinding of the callstack). Its almost like the person who came up with mechanism wasn't able to decide if the data was going to be a true member of the class or a true parameter on the stack. They decided to walk a confusing path between the two different concepts. Maybe we just need yet another keyword for BY-REFERENCE-STICKY. ;-) As far as BIND goes, I avoid that wherever possible, since the pattern is ugly, and less familiar, and in most cases can be replaced with BY-REFERENCE ( / REFERENCE-ONLY). The place we use BIND is to *permanently* "borrow"/"share" a dataset from a class that declared it *without* "REFERENCE-ONLY" to one that declares it *with* "REFERENCE-ONLY". We will declare data *without* the "REFERENCE-ONLY" keyword is in a remote class whose only purpose in life is to be used as a "dataset factory". It creates and distributes new instances of static data. But this means that any business logic class can then call the factory and ask for the static data via "OUTPUT DATASET DS_GiveMeYourFreshData BIND". The nice thing about BIND is that creates a "sticky" reference and the business logic class won't lose hold of that reference, once it has been acquired. To summarize, (and I hope this doesn't sound too negative) I think the biggest complaint is all the false confidence that you get from the compiler, and have to wait until run-time to see what you did wrong. Even then, some of the runtime error messages related to static data parameters are very, very bad - they are some of the worst runtime messages you will ever see from the AVM. Next, I think the implicit "unbinding" of BY-REFERENCE parameters from an OO class instance is very unfortunate. It seems to happen arbitrarily when the flow-of-control finally exits the original method that provided the input data Finally, I think that it is unfortunate is that the default behavior for passing static data is NOT by reference. Maybe we could start over with a whole new mode where all the default parameter passing of static data is by reference. Then you could have a new set of keywords (DATA-COPY, or BY-VALUE) when you really wanted your static data to be copied by value. I am somewhat biased in my opinions since I do just as much programming in .Net as I do in ABL. Maybe someone who works in ABL all the time (and avoided the OO-ABL stuff) would not have as many complaints as I do.
Continue reading...
Continue reading...