Opened 5 years ago

Last modified 5 years ago

#21638 new defect

CategoryObject should not inherit from ParentMethods

Reported by: tscrim Owned by:
Priority: major Milestone: sage-7.4
Component: categories Keywords:
Cc: sage-combinat, nthiery, jdemeyer Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges


A consequence of #20686 is that any class in a category inherits methods from ParentMethods. This means that subclasses of CategoryObject are treated like parents, but they are not parents. In effect, this makes CategoryObject a useless class, but I contend that sometimes we want objects which are known to be in a particular category that we do not want to behave like parents.

This is what causes the failures at #21386 and #21387.

Change History (5)

comment:1 Changed 5 years ago by tscrim

Granted, #21386 should be made into a proper parent following (finite) ChainComplex. However, #21387 does not have a natural basis (or really very computable), so it would be fairly artificial for it to have elements. Nevertheless, I feel like this is a bit of an overreach of ParentMethods.

comment:2 in reply to: ↑ description Changed 5 years ago by jdemeyer

I understand the problem, but I don't agree with the proposed fix.

I think that a CategoryObject really should allow inheriting methods from the category. So my proposal would be to fix the places where ParentMethods assumes that something is a Parent and not a CategoryObject. And then maybe rename ParentMethods...

comment:3 Changed 5 years ago by tscrim

I agree that CategoryObject should allow inheriting of methods, but not those from ParentMethods. I think there probably is a use for having non-parent objects in a category (with parents), although I can't think of one off the top of my head.

I don't mind too much downgrading IntegrableRepresentation in #21387 to a SageObject and removing the category (which is what is done for the Hecke representations). However, I think that is a small step backwards.

comment:4 Changed 5 years ago by nthiery


Agreed, ParentMethods can be a misnommer (see discussion below).

However, by definition, a parent in Sage is an object in a subcategory of Sets (which should, at this stage, be equivalent to being an instance of Parent). Therefore, if some method assumes that x is a parent, then it should be in C.ParentMethods, where C is a subcategory of Sets. Hence, a general category object should not inherit from it unless it's a parent.

So, in the #21386 and #21387 some of this logic must be violated.

About the ParentMethod name. What if a category C wants to provide methods to its object when it's not a subcategory of Sets? We currently put it in C.ParentMethods which is a bad name in such a case; we would want instead to put those methods in a class C.ObjectMethods.

But then it's less uniform, as parents need to get their methods from C.ParentMethods or C.ObjectMethods depending on whether C is a subcategory of Sets or not.

This tension has bothered me for a while, but so far, with very few categories that are not subcategories of Sets I tend to think that's overkill to try to fix this.

I think there probably is a use for having non-parent objects in a category (with parents)

That seems against the definition of Parent.



comment:5 Changed 5 years ago by tscrim

Sorry for taking so long to respond.

According to the doc of Parent:

Parents are the Sage/mathematical analogues of container
objects in computer science.

So a parent must be considered as something having elements we can construct.

AFAIK, all of our categories are presently concrete categories (modulo implementation detail categories like facade categories).

Let us consider the category of finite-dimensional vector spaces (e.g., over Q), where for a generic vector space, we could never create elements because we need a specified basis. We have a class that does this: FiniteRankFreeModule, but it gets around the issue by having generic elements in a generic basis.

In this case, we know we can construct a basis, but what if we go to infinite-dimensional modules over Z? It is still a concrete category, but what if we want to represent some generic object in this category (which is #21387)? I guess what I am challenging is this part of the definition:

(which should, at this stage, be equivalent to being an instance of Parent)

If we decide to have an object be a subclass of Parent iff it is in a concrete category, then we should document this. We should also either add a check in the category initialization that raises an error if this is violated or an additional _test_is_subclass_parent in Sets.ParentMethods.

A third way out of #21387 that I see is to have a completely generic element class. (I will fix #21386 so that that is a proper parent.)

Note: See TracTickets for help on using tickets.