Hi!

At sage-algebra, there currently is a thread about refactoring
sage.structure.element.Element, since some people think that Element
should not have a category -- currently, 1.category() yields "Category
of elements of Integer Ring", which may sound odd and yields no
information that isn't already in 1.parent().

But removing category() from sage.structure.element.Element does not
suffice, since it inherits from SageObject, which has a category() as
well (returning the "Category of objects").

In the thread, Niles asked:
> ... But I thought it was
> against the spirit of object-oriented programming to remove methods
> from a derived class.  I tried once very hard to figure out how to do
> it, and couldn't find a good way -- do you have one?  (And do you not
> feel guilty when doing it? :)

I think I found a technical solution for what Niles asked. Personally,
I believe that this solution is totally silly (although I do not feel
guilty), and I do not intend to use it for the project mentioned above
(instead, I want to move SageObject.category and
SageObject._test_category to CategoryObject, where it clearly
belongs).

But Niles suggested to ask here whether some people think that, what I
describe below, might be a useful programming tool and should be
available somewhere in Sage.

First, let me remind you two typical ways of inheritance:

sage: class Foo(Parent):
....:     def __init__(self):
....:         Parent.__init__(self)
....:         self._init_category_(Rings())
....:
sage: F = Foo()

F inherits a method an_element() from the class Parent (this is usual
Python), and it inherits a method product_from_element_class_mul()
from sage.categories.magmas.Magmas().parent_class (this is Sage's
category framework):

sage: F.an_element
<built-in method an_element of Foo_with_category object at 0x456ad70>
sage: F.product_from_element_class_mul
<bound method Foo_with_category.product of <class
'__main__.Foo_with_category'>>


Now, let us define an eraser:

sage: class Eraser(object):
....:     def __get__(self,inst,cls=None):
....:         raise AttributeError
....:
sage: erased = Eraser()

We can now define a class that inherits from Parent, yielding
something in the category of Rings, but its instances do *not* inherit
an_element or product_from_element_class_mul:

sage: class FooBar(Parent):
....:     def __init__(self):
....:         Parent.__init__(self)
....:         self._init_category_(Rings())
....:     an_element = erased
....:     product_from_element_class_mul = erased
....:
sage: F = FooBar()
sage: F.an_element
Traceback (most recent call last):
...
AttributeError: 'FooBar_with_category' object has no attribute
'an_element'
sage: F.product_from_element_class_mul
Traceback (most recent call last):
...
AttributeError: 'FooBar_with_category' object has no attribute
'product_from_element_class_mul'


Note that both methods still appear in dir(F) and in TAB completion.
Also note that the erased methods are still available with Python's
"super":

sage: super(FooBar,F).an_element
<built-in method an_element of FooBar_with_category object at
0x7f31012afd70>
sage: super(FooBar,F).product_from_element_class_mul
<bound method FooBar_with_category.product of <class
'__main__.FooBar_with_category'>>


Niles wrote:
> * There might be an argument to be made that the existence of an
> Eraser class would allow people to be a little more lazy and/or sloppy
> when they consider designing code and write code: "Don't know what to
> do when half of your inherited methods don't make sense? Just Erase()
> them!".  On the other hand, the added freedom might get more code
> written and added to sage when people don't get "stuck" on a design
> issue related to tricky inheritance.

And he replied further:
> > Yeah, might be good to ask on Sage-devel. I think the eraser is a
> > silly idea, but perhaps people disagree and like to use it...
>
> Well, "silly" was one of the first thoughts I had too, but upon
> further reflection I do think there's a reasonable use-case for it.
> Couldn't hurt to see what people think anyway . . .

So, what do people think? Shall it be provided as a programming tool
somewhere in sage.misc, or should it be banned, burnt and buried
(that's what I think)?

Cheers,
Simon

-- 
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

Reply via email to