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-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
