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-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.
