I would agree with you as long as the value of the array is properly namespaced. For example, if you did D UPDATE^DIE(,"FDA","IEN","ERR") then Fileman through indirection would end up setting the arrays FDA(), IEN(), and ERR(). None of these are properly namespaced and are not NEW'd by Fileman. Therefore any changes to these arrays will leak out through all procedures. If something in Fileman is invoked which itself causes FDA() or IEN() or ERR() to be set, then those changes will be leaked backed to your application and now you have corrupted arrays. That is the reason the SAC states that whenever calling an external API that requires pass by reference or pass by name you must used properly namespaced references. If that entity that was invoked by your Fileman call had NEW'd FDA,IEN,ERR prior to causing those arrays to be set then the changes to those arrays by that entity call would not have leaked back to your application. This explains why sometimes it works and sometimes it does not. It should always work as you expect if your application ALWAYS properly namespaces its external calls.
----- Original Message ----- From: "Greg Woodhouse" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 13, 2004 7:44 PM Subject: [Hardhats-members] parameters and namespaces (was: Mysterious DIERR message) > Actually, I think you're perfectly safe using "FDA" as a name for your > FDA array, since all references are through indirection of a DI* > subscripted array. > > Namespaces pose an especially difficult problem when variables are > passed by *reference*, and less so when the array name is passed as a > value parameter (I'm tempted to call this passing the parameter by > name, because it isn't too much of a stretch to think of the > indirection as using a thunk, but I digress). > > At any rate, the problem occurs when name of the formal parameter > collides with a variable in the calling symbol table, so it seems to me > that a more sensible rule to namespace formal parameters (though this > doesn't help much with intrapackage calls!) This is a nasty problem, > and something else I'd like to see changed in MUMPS. There really is no > reason why this problem could not solved in such a way that name > collisions are impossible. And yes, I do think cleaning up these > "glitches" would go a long way towards increasing the appeal of MUMPS. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
