Changes between Initial Version and Version 1 of Ticket #13566, comment 21


Ignore:
Timestamp:
01/01/13 20:45:45 (7 years ago)
Author:
nbruin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #13566, comment 21

    initial v1  
    99Yes, that sounds looks like a sensible approach. Additionally, if that seems like a heavy-weight solution (it does to me), one should probably see if uniqueness is so important that it warrants a subclass and/or if there are other pressing reasons to make these subclasses. Reasons against uniqueness:
    1010
    11 - `SimplicialComplex` is not a parent so there's sage-technical reason to enforce uniqueness (that's just a reason not ''for'' uniqueness)
     11- `SimplicialComplex` is not a parent so there's no sage-technical reason to enforce uniqueness (that's just a reason ''not for'' uniqueness)
    1212
    1313- While any two `Sphere(3)` complexes are isomorphic, they are not canonically so, so mathematically there can be good reasons to have multiple non-identical spheres in memory.
    1414
    15 - It makes things like `Sphere` behave different from `SimplicialComplex` (and more generally not simple ''be'' a `SimplicialComplex`. That makes code harder to maintain because now you have similar-but-subtly-different acting objects. You should only do that if there's a benefit elsewhere.
     15- It makes things like `Sphere` behave different from `SimplicialComplex` (and more generally not simply ''be'' a `SimplicialComplex`. That makes code harder to maintain because now you have similar-but-subtly-different acting objects. You should only do that if there's a benefit elsewhere.
    1616
    1717Should uniqueness of `SimplicialComplexes` be desirable in general (why? are they meant to become parents?) then it should perhaps be fixed on that level. Mutable obviously can't be forced to be unique, so then you should probably make two: `SimplicialComplex` and `MutableSimplicialComplex` (one a subclass of the other if at all possible), where you can make the immutable one unique by also inheriting from UniqueRepresentation. Going to the immutable one then of course should return an immutable ''copy'', not just change a flag.