Changes between Initial Version and Version 1 of Ticket #10963, comment 260


Ignore:
Timestamp:
01/05/14 17:44:24 (7 years ago)
Author:
nbruin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #10963, comment 260

    initial v1  
    77In addition, `_base_category_and_axiom` is a lazy class attribute, so it has a cache of its own. Why are we caching things twice?
    88
    9 Finally, and there are some design decisions in the ticket itself: Currently, there is code that relies on packages being in `sage.categories` by looking at the `__name__` and doing string mangling on it. Furthermore, it relates the class name `CamelCase` to the module `camel_case`. These are all fine a programming ''conventions'' but I find it questionable if it's a good idea to engrave them in ''program logic''. This is what I referred to when I wrote "doesn't read like python" above. If this were happening in a specialized little corner it wouldn't be so alarming, but categories are supposed to be a fundamental tool to govern inheritance in sage and hence part of the infrastructure. That means a lot of people will have to touch and maintain it in the future, so such code should really be held to a higher standard in terms of understandability, cleanness, and design.
     9Finally, and there are some design decisions in the ticket itself: Currently, there is code that relies on packages being in `sage.categories` by looking at the `__name__` and doing string mangling on it. Furthermore, it relates the class name `CamelCase` to the module `camel_case`. These are all fine as programming ''conventions'' but I find it questionable if it's a good idea to engrave them in ''program logic''. This is what I referred to when I wrote "doesn't read like python" above. If this were happening in a specialized little corner it wouldn't be so alarming, but categories are supposed to be a fundamental tool to govern inheritance in sage and hence part of the infrastructure. That means a lot of people will have to touch and maintain it in the future, so such code should really be held to a higher standard in terms of understandability, cleanness, and design.
    1010
    1111Writing a document that explains how to work with it and maintain the code might help, but isn't enough: documents tend to get out of sync with code over time (even docstrings!). But at least it would mean we have a record of the original author's intent.