Thus spake swampwallaby:
Joel,
Could you gove some examples of what a Hierachical Key will look like. I
can see several problems with your proposal, including bdgza’s concerns,
that might become clearer if I know what a hierachical key looks like.
I was expecting that an item appearing as Foo > Bar > Baz in a contex
menu would have a key that reflected that, something like ‘/Foo/Bar/Baz’,
or, maybe the levels represented as a list, to avoid having to parse the
string each time.
On reflection, its not necessary that this key serve as both as a name
and a menu location. Those could be separated if it would be problematic
to have them together.
Think about the case 2 different ‘Actions’ without keycodes that are to
be triggered at the same time by the same user event. What will the
hierachical keys look like? What binds them together? The
NamedKeyStrokes I did for 3.2 are essentiall an ‘Activation Id’ that
other ‘Actions’ (ie. traits) can look for and act on
I suspect that I’ve misunderstood what you’re saying for this one.
What the hkeys look like would depend on where and in what menu the
associated Actions were to appear in.
It should never be the case that two Actions are triggered at the same
time, because the user can’t input two separate key events simultaneously
on one keyboard or select two menu items simultaneously.
I am also unsure about your scheme to index ‘by property’. What you seem
to be saying is to index the property values of each possible property,
so there would be one index for each possible Vassal property. You would
need a database query optimizer to use that to help with a search for
something like ‘CurrentMap ~= Veghel* and Strength < 5 and Will >= 12
and (hp == 2 or hp == 3)’
What I’m proposing w/r/t indices is that when a particular search is
done for the first time, we cache the result and install change
listeners to keep that cached result current. I don’t see why that would
require a query optimizer. Running the same query a second time should
result in returning the cached list, not doing another search.
Following your example: this would involve adding a change listener
which looks at the values of the four properties in your query, to be
added after the first time the search is done. Subsequently, whenever
any of these properties change, the change listener would add or remove
pieces from the cached index as appropriate.
I suspect that this is better than keeping sorted per-property lists for
every property—doing that would put us in need of a query optimizer of
some sort, as there’s no obvious way to retrieve lists of pieces which
satisfy complex queries there—because it will have us keeping indices
only for the exact queries which are actually used.
–
J.
