How is this done in relational databases? There has some be some sort of language to evaluate the database. SQL is a language, I guess.
It seems that a M database is a more "organic" creature -- containing code to protect itself etc. Probably relational databases can do this too, but at our site at least, it is not done. For example, when our front staff put in goofy social security numbers, the database is perfectly happy to accept these erroneous values. So I am guessing that to be insulated from M would require an introduction of some different language as a replacement. I can't see that happening. Kevin On 2/6/06, Greg Woodhouse <[EMAIL PROTECTED]> wrote: > First of all, I need to clarify that I am not talking about the way > Fileman is implemented. I'm not talking about rewriting it in some > language other than MUMPS. Rather, I have in mind modifying Fileman so > that people *using* it (both as programmers and as users) do not have > to work directly with the underlying global subsystem or embedded code > such as input transforms, screens, cross-refereences, etc. It seems to > me that in many, if not most cases, Fileman does an admirable job of > insulating both usewrs and programmers from the details of the > underlying implementation (e.g., by building input transforms and > computed expressions from high level descriptions, by choosing > reasonable defaults for global storage locations, and so forth). But it > stops short of achieving full language independence. This is > unfortunate, because it forces would-be VistA developers to deal > directly with what should be system internals, and is a major obstacle > to providing support for multi-language development in the VistA > environment. > > It's not an issue of whether MUMPS is or is not a good language. C is a > perfectly good language, too, but how many programmers would want to > use Unix as their primary development platform if it were the only > language choice available? There are certainly obstacles to making > Fileman language independent, and I don't mean to suggest that it would > be easy, but I do think VistA would benefit. If nothing else, it would > benefit from the increased pool of potential developers and greater > ease of integration with other systems. The biggest obstacle would, of > course, be backward compatibility. People are used to $ORDERing through > the "B" cross-reference, or writing their own screens and identifiers, > and code using these techniques isn't going to just go away. But right > now, it's not even possible to write code that avoids delving into the > internals, at least at some level (or in some cases, it is possible, > but the performance cost is unacceptable). > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > "All truth passes through three stages: First, it is ridiculed. > Second, it is violently opposed. Third, it is accepted as > being self-evident." > --Arthur Schopenhauer > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
