|
I have offered some comments and ideas below, BUT actually this starts
us down an interesting path. The VA is not about to undertake these
kinds of mods. So does the community want to create an effort to build
a FM that is superset of the VA's FM? Would it be possible to keep it
in sync with VA changes? Intriguing.... Greg Woodhouse wrote: That is cool. Some of these are already there, depending on how you think about it. Like the "ID" logic to display fields, the "SCR" node for screening, the "DEL" node for deletion protection, "LAYGO" nodes for adding logic, etc. In each of these, there is a variable defined by FM as the 'this' value.That makes me wish all the more I was going to be there! :-( Anyway, I think we all know that it is possible to do more harm than good by overloading a good product with features. That being said, when I think about how I use Fileman, there are a number of possible areas for improvement and/or enhancement that suggest themselves:1) I've noticed (usually after the fact) that I frequently end up passing an IEN from my "base file" as the first paramater of a function or entry point specifically so that I can operate on that record in some way. This is a sure sign that I am simulating methods by explicitly passing a "this" (or "self") pointer. Could Fileman explicitly support methods?
Perhaps this would be an attribute to set in a file's DD for a
permanent effect and/or it could be invoked dynamically with some
character at look up time (like we use ' to mean lookup by number).It is already there, to some extent. Just use EN1^DIP and define the DIS() array. The FM docs are particularly sparse on this subject, but just treat the DIS() like the way DIC("S") works with D ^DIC.3) This is sure to be controversial, and I haven't made up my mind what the right behavior should be, but should keys be nullable? I think Oracle, for example, allows nullable keys (some key fields may be null, so long as the combination is unique), but I think there is a real danger that the need to make keys nullable is a symptom of an underlying normalization issue. Requiring all key fields to be non-null (the way things are now) may be a good feature. 4) I would like to see search made available through a "silent" call. Check out the FF of file 1.01. That might be an example of what you are looking for.5) I would like to see an "IS" operator added to search allowing search by identity (equality of pointer value and the IEN of the referenced record). 6) High volume applications have reported that getting new IENs by reading and updating the file 0-node can be a bottleneck. Can this process be optimized? 7) Might it be possible to create "local files" that are not stored permanently in a global namespace, perhaps even "files" that exist for for a single session only? This is a feature that I think would be useful to programmers wanting to use Fileman tools to work with "objects" in their programs that do not need to be stored permanently. 8) Should Fileman support inheritance? In many ways, Fileman provides aspects of OOP at the database level, but this is a notable exception. There are mechanisms like variable pointers, of course, but they are not especially "clean". Would it be useful to say, for example, that PATIENT is a person and an EMPLOYEE is a person (note that I'm not referring to the current file structure) and have polymorphic pointers that would be dereferenced appropriately (perhaps through some kind of introspection under the hood)? 9) Why not provide a GUI interface to Fileman? 10) General simplication -- if you accidentally step into Fileman using the debugger, it seems to take forever before you come out again. Does Fileman need to do that much work? Could the code be optimized/simplified? --- Nancy Anthracite <[EMAIL PROTECTED]> wrote: |
