I agree with you, but there are (at least) two questions left hanging: 1) is the database transient? i.e. repopulated once as the code is run? 2) nathann is arguing on the feature-length trac ticket that we are writing together that empty methods have no place in sage if they only exist for the decorator: http://trac.sagemath.org/ticket/16403 The same arguments were made (by him and others) in Edinburgh, and indeed miss the point of ABCs (made in the trac ticket) and the category framework (not made in the trac ticket, because I only want to kick one can of worms at a time)
Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 12:51 AM, Simon King <simon.k...@uni-jena.de> wrote: > Hi Paul, > > On 2014-05-27, Paul-Olivier Dehaye <paul-olivier.deh...@math.uzh.ch> > wrote: > > For anyone involved in findstat, there are several layers of complexity. > > This is my assessment from outside the findstat collaboration: > > - they also deal with Mathematica code > > - they also deal with user-generated information that is not code > > You just provided two arguments for having an external database :) > > > - they also develop some of the code and would thus 1) prefer to > maintain > > one rather than two separate objects (code and database) > > That's no valid argument. Currently, they simply put a decorator in front > of a > method. In future, they'll simply put a decorator in front of a method. > > The important difference is that now the decorator is replacing a proper > method by an instance of some class, which is an intrusive way to encode > information that is supposed to be retrieved by a function that is hidden > somewhere. But in future the decorator will be writing to some database > with > a standard database engine, without replacing the method by something else. > > > 2) like to easily > > and flexibly be able to develop the code as they intend to use it (i.e. > > equipped with everything, cf. monkey patching) > > Again, this seems unrelated to the question of what the decorator should > do. > > > - some of the information they want is added/could easily be added by > > others in sage code > > Again, adding information is now and shall in future be possible by putting > a decorator in front of methods. > > > > - just like the LMFDB, the database term is a misnomer. They want their > > thing to be data and code. > > So, why don't they focus on their data and code? Why do they spend their > time > with an ad-hoc implementation of a mock-database in an intrusive way? Do > not re-invent the wheel, and try to use the right tool for a job! > > Let me try to re-formulate it: > - There should be a database, locally stored in SAGE_SHARE, but perhaps > even able to talk with some remote database. This database would also > be able to deal with external information, from Mathematica or other > sources. > - The @combinatorial_map decorator will be one (the easiest?) way to > register stuff in the database. > - The user should in future have additional possibilities to register > stuff and > do queries, namely by a proper database interface. > > Best regards, > Simon > > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-de...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
