On Oct 31, 11:41 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Oct 31, 2007, at 8:40 PM, Carl Witty wrote:
> > 2) The automatic detection of possible actions scares me. It seems
> > fragile and overly magical. Would it be possible to disable this
> > (which would presumably slow things back down), then document a way
> > for classes to have fast coercions/actions (preferably in the
> > Programmer's Guide)?
>
> Right now, to define an action, one simply has to define any of
> _rmul_, _lmul_, _r_action_, and _l_action_. The first two assume the
> other element belongs to the basering. Is there a simpler way for the
> _user_ to define an action?
I think what I mean is that most of get_action_c_impl should be
removed, and that parents that want fast actions should be required to
set ._action_list (presumably by passing actions= to
Parent.__init__). In particular, comments like:
# TODO: if _xmul_/_x_action_ code does stuff like
# if self == 0:
# return self
# then _an_element_c() == 0 could be very bad.
worry me.
It seems like you're trying to guess things about how types are
implemented by probing them from outside, and that this is likely to
break for slightly-odd types.
Perhaps I wouldn't be worried if there were a clear, not-too-
complicated checklist for how to make sure a type works with the
coercion model. Things like "if _r_action accepts any value with
parent A, then it must accept all values with parent A" -- if that is
indeed a requirement of the coercion code.
Carl
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
