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

### Description

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.

### Change History (5)

### comment:1 Changed 5 years ago by

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

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

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

Hi!

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 `x.foo`

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`

.

Cheers,

Nicolas

### comment:5 Changed 5 years ago by

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.

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`

.