Hi all,

Shoot, I missed this thread one month ago ... My view point in two
sentences:

In theory I would want to get rid of all the ModuleElement /
RingElement / ... hierarchy of classes. The rationale is that this
hardcoded hierarchy just does not scale: it's impossible to model but
very few categories, in particular due to single inheritance. That's
precisely because of this scaling barrier that we introduced the
category mechanism [1].  And indeed, when I write my own parents, I
almost never derive from the *Element classes.

However, at this point in time, one cannot yet cythonize methods in
categories. Thus, for the time being, we still recourse to this
hierarchy of cython classes for those critical parents where
arithmetic is so cheap (e.g. finite fields, ...) that we can't afford
the overhead of going through a Python method call.

In short, the plan I have always had in my head is to:

- move all non time critical methods from the *Element hierarchy to categories
- make have all non time critical parents not use the *Element hierarchy
- explore the cythonization of category methods
- explore good idioms to do more type checking
- hopefully someday deprecate the *Element hierarchy and get rid of it 
altogether

Cheers,
                                Nicolas

[1] Hopefully the new primer coming with #10963 will make this point clear!

--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to