There is one problem with the strategy I've proposed of using mixins to handle different possible arguments to format-graph-from-roots:
1. Recall the proposed strategy:
a. add a mixin class that would be something like HASHABLE-GRAPH.
b. move the HASH-TABLE slot from STANDARD-GRAPH-OUTPUT-RECORD to HASHABLE-GRAPH. Add a NODE-LIST slot to STANDARD-GRAPH-OUTPUT-RECORD.
c. Add a FIND-DUPLICATE-GRAPH-NODE generic function that would do linear search on NODE-LIST by default, but that would do a hash lookup if the graph-output-record were of type HASHABLE-GRAPH.
d. Given a call to FORMAT-GRAPH-FROM-ROOTS, if DUPLICATE-TEST were one of the acceptable values (EQ, EQL, EQUAL or EQUALP), then make the hash-table, else use NODE-LIST.
2. Problem: as far as I can tell, this would make (if you pardon the pun) a hash of the existing McCLIM graph-type declaration process. Recall that when one defines a new graph-type, one needs to call DEFINE-GRAPH-TYPE to create a mapping from graph-type name (by convention, it seems, a keyword symbol, but could be simply a symbol) to graph-output-record subclass. But this approach isn't really compatible with the approach I've outlined in #1, above, since we'd need to be creating (at least) TWO new classes, one with the HASHABLE-GRAPH mixin, and one without, and the person defining the graph-output record would have to know about this difference.
3. Possible work-arounds:
a. Avoid using CLOS and method dispatch to solve this problem. Instead, create a DUPLICATE-GRAPH-NODE function that is *not* methodified, but that simply checks the value of duplicate-test, and either uses a hash-table or not, as appropriate. Somehow this bothers me, but not as much as:
b. Do something scary involving CHANGE-CLASS.
The route of least resistance is clearly:
c. Go ahead and violate the CLIM spec, and restrict DUPLICATE-TEST to be one of EQ, EQL, EQUAL or EQUALP. Note that *this is the status quo* --- the existing McCLIM code already makes a graph node hash table and initializes it using DUPLICATE-TEST, so I will just be continuing in the current line, not adding any new spec violations. Actually, note that if we don't want to choose this alternative, I actually need to fix existing code --- it's not enough to just add code, I actually need to fix the existing graph layout code
If I had this to design ab initio (not that I would dare to design a graphic interface spec myself), I would just do 3(c), and make the spec limit DUPLICATE-TEST to one of the hash-able values, which seems far better.
Anyone have a vendor CLIM license and know if they support arbitrary DUPLICATE-TEST values? Reading the Franz user's guide suggests that they do.
Unless I get a strong vote for 3(c), I will follow 3(a), and try to have a patch RSN.
BTW, shouldn't McCLIM cough up a hairball if you try to use format-graph-from-roots with :merge-duplicates t and :graph-type :tree?
Cheers, Robert