Two comments: - Nathann is arguing that no empty methods/classes should be present. Which means to me that he doesn t see the value of semantic information in itself - 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 (partially redundant work: cf http://nforum.mathforge.org/discussion/2490/what-would-you-want-from-a-higher-categorical-database/#Item_0). In any case, the way findstat does things, they have the potential to construct a database. The point is that they allow me to reuse their work to easily build my own database on top, that does something different.
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. 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 5:23 PM, Simon King <simon.k...@uni-jena.de> wrote: > Hi Christian, > > On 2014-05-28, Christian Stump <christian.st...@gmail.com> wrote: > > But how am I then convincing > > someone knowing that information to add that information there? > > Ask him/her to put @combinatorial_map in front of the method in > question. In other words, there should be no need to change the interface > for those who contribute combinatorial maps. What should change is how this > contribution is processed. It should not be the case that, as a result, > the overhead of calling a method increases! > > What I (an Nathann?) am trying to convince y'all: @combinatorial_map > should not wrap a method into some class instance that serves as a proxy > to the method and holds additional information purely locally. Instead, > @combinatorial_map should communicate with a (local) database before > returning the method *unwrapped*. And then, there should additionally > be tools to use the local database together with a global one. > > > > What I > > like about a local system (preferably accompanying the code of the > > very method) is that it makes it easy for the person having > > information about a specific map to provide that information. > > To give you a drastic picture: Imagine you work for a company and want > to keep track who is your customer. You suggest to attach a little tag > to each customer, stating that (s)he is "happy customer of FooBar ltd.". It > will then be very easy to test if a given person is your customer: Just > look for the tag. And when you want to have a list of your customers in > a given town: Just do an exhaustive search in that twon and check each > person's tag! > > But I somehow feel that having a database keeping track of your > customers would be better. And I do believe that tagging a method as > "combinatorial map" locally is the same as tagging your customers > locally. So, the picture applies. > > > Of course, that information must be organized to be searchable > > properly. But I don't see a problem there beside conventional namings. > > Hang on. Do you suggest to implicitly create a database that relies on > naming schemes?? > > I think one can not deny: What y'all do with the @combinatorial_map *is* > in fact creating a database---at least implicitly---, whether you want > it or not. But explicitly is better than implicitly, and one should not > re-invent the wheel. So... > > 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.
