[mcclim-devel] question about CLIM spec [format-graph-from-roots]

[Robert P. Goldman]

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