Hi Viviane, On 2014-05-27, Viviane Pons <vivianep...@gmail.com> wrote: > The way it works: the decorator replaces the tagged methods by instances of > combinatorial map class, the functions only checks which methods are indeed > instances of this class.
And, if I understand correctly, it is this kind of things that makes Nathann ask for removal of the decorator. What you *want* to do is create a database that handles requests of the type "what combinatorial maps are provided by a class C?", or perhaps even better "what combinatorial maps are provided by a sub-category S of Sets().Finite()?". This could very well be a (SQLAlchemy?) database that is stored somewhere, perhaps even in a remote location. But what you *do* is to encode this database via the *type* of methods. The information is not put into an external database, but the information is stored *implicitly* by changing Sage code. I agree with Nathann: This is intrusive! And when your decorator replaces methods by "instances of some class" then certainly the overhead of calling these methods will increase. Applying your decorator to a frequently (recursively?) used method may result in a slow-down, as it seems. Even when trying to take your perspective, I still don't understand why you might want the decorator to work in that way. Certainly a proper database (relying on a dedicated database engine) is faster and easier to search and thus more useful for you than an ad-hoc function that ultimately relies on listing attributes and determining their types. So, what is the rationale for *not* using a database for your database of combinatorial maps? > It is partly the information you need even so I'm not sure it's a good way > to have it. I see no reason how this could be a good way to have it. > And also, this function is hidden somewhere and not accessible > from the object or the parent itself. "Hidden somewhere" is bad for a user interface. > About Nathan's suggestion to have a flag, I don't know if it's such a good > idea. The idea is to provide this semantic information to any user of Sage > not machines. It seems to me that you are argueing *against* the current decorator. Calling a function that is hidden somewhere and relies on introspection (listing attributes, type check) is for machines. A user of Sage should have a database with a proper interface. > The way I see this, *because* of the FindStat use case, the > combinatorial_map decorator has been introduced and many Sage developers > have been devoted time into adding semantic information into sage methods. > Of course, we could remove this all together, but this would be a great > loss for Sage as this semantic information is useful for users. And Here, I > speak as a combinatorist person working with these objects every day. > > So, our concern should be: how to make this information easily available to > users and how could we store this without impacting efficiency of the > program. Do not store information by a decorator that changes code. Migrate it to a proper database, that may be stored in SAGE_SHARE. The decorator should write information into the database (or perhaps even pull information from it?) and, when done, simply return the unaltered method. In that way, it would not be intrusive, and the database would provide a not-so-hidden single point of entry. 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.
