On May 31, 2010, at 3:06 PM, William Laffin wrote:
I've brought this one up before. How do folks feel about having the
named permutation groups available like graphs are? In other words,
rather than each family of permutation groups being a new class,
there
is a single system-wide object ("groups", or "perm_groups") whose
methods produce instances of permutation groups (or more generally,
just groups). So for example,
D=groups.DihedralGroup(7)
would replace the above syntax. Advantages - namespace is less
cluttered, and tab-completion (groups.<tab>) gives precise one-stop
shopping for examples of specific groups.
I'm +1 to a group object like this, but removing things from the
top level
namespace is backwards incompatable and could break a lot of code
out there.
What is wrong with using sage.misc.misc.deprecation?
That doesn't prevent breaking people's code, just warns them about it.
Preserving backwards compatibility is hard enough as it is (especially
for people of upgrade infrequently, or if there are publications using
the old syntax) so I'm +1 to not adding new names to the global
namespace, but think there should be really good reasons before we go
an remove stuff.
As for classes vs. methods, one advantage of classes is that
sometimes
certain methods can be simplified/optimized if you know what
specific group
you have.
I might be off on what you are trying to say, and I'm not fully pro
with gap but I believe depending class inheritance with group theory
is inherently too weak. Applicable methods installed into operations
that are dynamically chosen at runtime based on some fitness criteria
(what gap has) seems smarter than dynamic classes (operations chosen
by class hierarchy only). This applies specifically to group theory,
where there are many different ways to deal with groups, and some
properties are more important than others when dealing with different
functions.
http://www.gap-system.org/Manuals/doc/htm/tut/CHAP008.htm#SECT002
I might be a gap fan boy here, but having many attributes in a small
number of classes with many private functions that are called from
public ones seems more robust than an extremely large class hierarchy.
I'm not advocating an extremely large class hierarchy, just saying
that it may make sense in some cases to have actual classes (if only
to provide extremely quick fitness criteria tests, though some of that
could be done with attributes as well). I'll leave it to the experts,
like you, to actually design the system.
- Robert
--
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
