On 12/7/10 8:06 PM, Minh Nguyen wrote:
Hi Jason,

On Wed, Dec 8, 2010 at 10:26 AM, Jason Grout
<[email protected]>  wrote:
I think maybe I was too brief in my suggestion to be clear.  I would favor
refactoring the code out to a spanning_tree.py(x) file.  My point was that
your propositions seemed to indicate that the graph class methods that would
call spanning_tree.min_spanning_tree would also do some additional error
checking, maybe have a different interface, etc. My suggestion was to not
have any additional code; put all of that error checking, etc., into the
spanning_tree.min_spanning_tree function.  In other words, the graph class
would simply import the functions into the class namespace:

class Graph:
    from spanning_tree import min_spanning_tree

That way we get a standalone function in spanning_tree.min_spanning_tree,
and we also get a convenient method for all graphs, and they are exactly the
same function, have the same interface, etc.  There is no duplication of
code or of doctests.

Of course, this import should probably be moved up to the generic graph
class, like you suggest, if the function can handle digraphs too.

The above seems very reasonable to me. Documentation for spanning
trees would be advertised on the top-level page for graph theory,
while we refactor spanning tree code into the proposed module
spanning_tree.py(x) and import min_spanning_tree() somewhere in
generic_graph.py. This means that one could still discover
min_spanning_tree() via tab completion (using a graph object) and also
have the code for min_spanning_tree() centralized somewhere.



Yep. Basically, the method becomes a convenient alias to the function in the spanning_tree module.

With this model, I can see one solution to the "method bloat". Common algorithms/functions have aliases as methods. Extensions or uncommon functions don't have aliases as graph class methods, but live in the spanning_tree module. I'm not sure how I feel about it, but it is an idea...

Jason


--
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to