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?
2) How should DIC work by default when a file has a compound key? I
know it is possible to set DIC("A",n), but should this be necessary?
When searching by record identity, should Fileman automatically prompt
for a value for each key field?
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.
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:
> I think George Timson will likely be discussing what is in the future
> for
> fileman at the upcoming meeting, so maybe that will be a good time to
> mention
> some things all of you think should be in its future.
>
A practical man is a man who practices the errors of his forefathers.
--Benjamin Disraeli
====
Greg Woodhouse
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
