Hi, and happy new year!

I wonder under what conditions there should be a deprecation warning
before removing a method: Can one do without a deprecation warning, if
the method does not really provide an apparent functionality? Or would
we argue: It is theoretically possible that some third-party code uses
it in some way, and hence there *must* be a deprecation warning before
removing a method?

The reason (or use case) for my asking is as follows:

At sage-algebra, 
http://groups.google.com/group/sage-algebra/browse_thread/thread/3e2ca2a8be1a3a23
, there currently is discussion about how to test that something is a
morphism in a category, and it also contains a discussion on the
meaning of "X in C" for a category C:
* Should it return True only for objects, or also for morphisms
(that's currently not the case)?
* Do we really want that "X.category()" sometimes does *not* return a
category containing X as an object? By consequence, we currently have
  sage: ZZ.hom([1]) in Rings().hom_category()
  True
which seems strange, as ZZ.hom([1]) is an element of an object of
Rings.hom_category().

There is a class SageObject, from which Element derives, and a class
CategoryObject, that directly derives from SageObject and from which
Parent derives. Clearly, CategoryObject should have a method
category()  --  but is there a reason why SageObject has a
category()?

What is the purpose of Element.category() returning the "category of
elements of a parent" (a category with trivial morphisms, or what?),
such as
  sage: 1.category()
  Category of elements of Integer Ring
?

Niles found that removing SageObject.category() and Element.category()
(which are different) is relatively harmless (of course, some tests
fail, but apparently it would be easy to fix).

Hence, it seems (at least to me) that SageObject.category() and
Element.category() do not really provide a functionality. But perhaps
someone here knows a reason for having them? I think that question
should be answered on sage-algebra.

But, what I'm asking here: If they really don't have a compelling
reason to exist and if we decide to remove them: Should there be a
deprecation warning, or not?

Best regards,
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