> - Nathann is arguing that no empty methods/classes should be present. I think he is, and add Vincent too (cf. previous email of his).
Absolutely noone wants unefficient code. If there is a clear way to improve, let's do it. But burden is on all of us. To be clear, I want to have this semantic information in the code. There are many reasons for this, here is one more: it provides an intermediate step for a person joining sage between a typo fix and implementing their first function, welcoming microcontributions. I think decorators would be very suitable for this, but am open to alternate suggestions. > Would this be a short-term solution? Sure! 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 8:47 PM, Simon King <simon.k...@uni-jena.de> wrote: > Hi Paul, > > On 2014-05-28, Paul-Olivier Dehaye <paul-olivier.deh...@math.uzh.ch> > wrote: > > Two comments: > > - Nathann is arguing that no empty methods/classes should be present. > > Is he? Sorry, then this is a point where Nathann and I do not agree. I > find abstract methods useful. I thought that his main point was: Don't > be intrusive! Do not make code of some people slower just because other > people care about the mathematical properties of some methods. And from > my perspective, the discussion is (or should be) only about the > question: How to care about the mathematical properties without slowing > down other peoples code. > > > - They are not building a database. They are putting tags in the code > that > > allow them at runtime to build something that amounts to a database. It's > > not that different to the category framework in some way, which is > encoding > > a lot of data via code constructions > > There was in fact some discussion at #10963 about the question whether it > is > a good idea that the new category-with-axiom framework encodes a > fully-grown > would-be-database (by this, I mean something that amounts to a database) by > purely local data and naming conventions. > > I'd say: If they are putting tags in the code then they *do* create a > (would-be-)database, whether they want it or not. > > > I am not arguing that what findstat does with a decorator is the best. A > > flagged decorator that does nothing most of the time is better than what > > they do. But a full-on database is, as a short term solution, heading in > > the wrong direction. > > Do I understand correctly: You would not like that the > @combinatorial_map decorator constructs a database at startup time? I > think that's a valid concern. > > We could try to be clever and introduce an environment variable (or > commandline argument) such that @combinatorial_map creates a database > when this variable is set, and otherwise does nothing at all. > > Hence, people who care about the implicit would-be-database encoded in > the flags could obtain them by explicit request, and all other people > would not be affected at all. > > Would this be a short-term solution? Also from Nathann's perspective? > > Cheers, > 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.
