There are certainly risks with indirection. But it's also very powerful and especially useful if you are writing generic utilities.
Fileman DBS calls are a good example. They can abstract the name/location of input, and output arrays. Different callers can use different arrays. This is only possible with indirection. The location can be in the local symbol table or on disk. It's even possible to make a change on the fly from local space to disk space, say when the data being manipulated grows large. It only takes a couple MUMPS commands to do it. Too often languages attempt to protect us from ourselves. I was taught that this was a good thing, but it's not. Dynamite is very dangerous, but it sure beats breaking big rocks with a hammer. Cars are also dangerous, but how much would we get done if we had to walk everywhere. Languages ought to make it easy to express solutions to complicated problems. MUMPS indirection does. That's not to say that everyone with a keyboard should use it. And not everyone should use dynamite, or operate heavy equipment, or drive a car. But everyone thinks they can drive, and it's those other idiots out there that need to be constrained. And everyone thinks they can code. I think everyone ought to have a car and keyboard, learn courteous driving and good programming style, and hope for the best. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruben Safir Sent: Wednesday, August 24, 2005 10:36 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] All about programming On Wed, 2005-08-24 at 19:04 -0700, Gregory Woodhouse wrote: > Now, MUMPS doesn't have pointers, but you can use a variable to > store > the name (or part of the name) of another variable, or even a > command. As a simple case, try the following > > SET X="HELLO" > SET Y="X" > WRITE @Y > > The @ operator is the indirection operator in MUMPS. What this code > does is lookup the value of Y to get "X" and then lookup the value > of > X to get "HELLO". > But this is an indirect reference and for the life of me, I don't know why language designers fall in love with stuff like this. The pitfalls are everywhere and there is always a better way to design something than doing this. This is like TCl hell. Now anyone can assign any variable the value of X, even from user input and bang, you have a nearly untracable bug. The running environment has an internal table of data it is storing. Just assign that key to the a variable and make a real reference. Then the symbol X can be recycled safely in the program and you still have a handle to the original data. Ruben ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
