On 2/14/20 4:53 PM, Kwankyu Lee wrote: > > +1 to cones.trivial() > > reason: there is no Trivial class or factory. >
I guess this comes down to how strict your definition of a factory method is. Traditionally, the factory pattern meant that you would ask for an object with certain properties and get back a subclass that met your needs. Indeed, with PolynomialRing, you can get back different classes, e.g. sage: PolynomialRing(SR,'x').__class__ sage: PolynomialRing(QQ,'x,y').__class__ With cones.Trivial(..), you always get back the *same* class, namely a ConvexRationalPolyhedralCone. So that is not a factory in the same sense. >From another perspective, if I didn't want to group these all under the "cones" prefix, what would I do? If I made them all subclasses of ConvexRationalPolyhedralCone, then there would be a class named Trivial and Trivial(..) would be used to construct one. But that's not what I'd do in this case, because I don't want to return a subclass -- I want to return a particular ConvexRationalPolyhedralCone. Thus I would have a top-level function named trivial() do the work, and if you wanted to preface it with its module name, it would look like cones.trivial(). But... is that the distinction that we want to make? I'm skeptical that the person who wrote that paragraph in the developer's guide had the 1995 definition of "factory" in mind. I actually like this convention, but it's a bit subtle. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b14c52ed-1880-89d2-6e85-34fb7aa324ee%40orlitzky.com.
