On Jan 11, 2010, at 10:49 AM, Nick Alexander wrote:
On 11-Jan-10, at 10:44 AM, Robert Miller wrote:
Nathann Cohen wrote:
The thing is that we have at the moment something like 210
functions
in the Graph class. We can not really keep on adding the new ones
without caring about what it is becoming.
In response, Robert Bradshaw wrote:
Why is that too many? I like being able to type g.<tab> and see
every single
method that is available. If one is interested in trees,
g.tree<tab>[<tab>]
gives a smaller subset. Or read the documentation.
+1
Of course, all of the above is just my opinion, it's worth hearing
what
other people have to say too.
I think that the natural place to divide things is *mathematical
objects,* not "types of methods." We can have the method names
provide
this kind of grouping (e.g. G.cliques_max_clique() instead
G.max_clique() or G.cliques.max_clique() ), but even that makes it
harder to write code, since you need to type more and remember less
natural method names.
This is an artifact of the fact that names are sorted and completed
lexicographically only.
I think I agree with this last sentiment. Why not have a
SetOfCliquesOfGraph object returned by G.cliques(), which is then
further interrogated? Ie, cliques = G.cliques();
cliques.max_clique(), etc. This worked well with torsion subgroups
of elliptic curves and in a host of other places (class groups of
number fields, maximal orders of number fields).
+1 This sounds like the right solution.
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
