comments below --- Greg Kreis <[EMAIL PROTECTED]> wrote:
> Hindsight is 20/20, but I sure wish that someone had seen the wisdom > of > creating a new class of array storage that had the following > characteristics. > > 1. Disk-based so it didn't impact partition memory Actually, I think the whole idea of a fixed size partition is a little outmoded. It makes sense, perhaps, if all local variables are stored on the stack, but what about heap allocated memory? True, in languages like C, such memory is typically accessed indirectly, but it could be made transparent. That being said, there are really two separate issues here, and whether or not a variable is persistent is probably best keep logically separate from the amount of memory/storage it requires. > 2. Temporary (automatically was killed when the process > terminated) This is similar to what we try to do with ^XTMP. Old nodes are not cleared when they pass out of scope, but instead a background process regularly kills nodes that are no longer needed. (With ^TMP, it is the programmer's responsibility to kill those nodes explicitly). I like the ideas of having "globals" (we'd have to come up with a different name!) that disappear when they go out of scope. > 3. Supported nodes with WORM features (not required for all nodes > of > the storage) Why not allow any variable to be explicitly declared "write once"? In C++, you can write const int j = i + 1; The variable j isn't a (compile time) constant, because its value depends on the value of i, but once it i set, it can't be changed. > 4. Supported the idea of private and public branches of nodes Another interesting idea. A lot of questions come to mind: Does "public" imply something like a traditional MUMPS global, or can it be more limited in scope? Is there room for name collisions? Must updates occuring in a different process be visible to the process having "private branches"? What about nested scopes within a single process? Coroutines? > > The SSVN concept seems like it would be a great way to implement the > above. Maybe there is no wisdom in what I described.... but either > way, > it is too late for VistA. The best we can do is instill consistent > programming practices to maintain backward compatibility, right? I certainly hope that existing VistA modules will be rewritten and enhanced over time. But I agree that it's possible to maintain backward compatibility. How do you envision using SSVNs in this context? > > Greg Woodhouse wrote: > > >I guess the subject line says it all. Can anyone make a case for > >supporting dynamic scoping rules? > > > >I realize that my previous post on this topic was a little unclear > >about the nature of dynamic vs. static scoping. Variables withing a > >nested block can hide variables by the same name in an enclosing > block > >under static scoping rules, too. A simplke example of something that > >does require dynamic scoping is > > > > > >S D=4 > >W !,$$INC(1) > >Q > >; > >INC(PI) ; > >Q PI+D > > > >Under static scoping rules, this code wouldn't even compile, because > >whether or D is within scope in the body of INC depens on whether or > >not it was bound when the call was made. > > > > > >=== > >Gregory Woodhouse <[EMAIL PROTECTED]> > > > > > > > >"Perfection is achieved, not when there is nothing more > >to add, but when there is nothing left to take away." > >-- Antoine de Saint-Exupery > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------- > >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 > >[email protected] > >https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > > > -- > Greg Kreis http://www.PioneerDataSys.com > > "You are today where your thoughts have brought you, you will > be tomorrow where your thoughts take you." (James Lane Allen) > > > > ------------------------------------------------------- > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
