Hi Nathann, On Fri, Sep 18, 2009 at 1:00 AM, Nathann Cohen <nathann.co...@gmail.com> wrote:
<SNIP> > The thing is that I am tempted ( for the Graph class ) to write many > functions I find useful, but these functions would very quickly crowd the > list of Graph methods... For example I am interested in computing > orientations of graphs, and there may be many functions needed... For > example, how could I include 10 or 20 functions dealing with one particular > problem of graphs without quickly transforming this already quite crowded > class in something impossible to browse ? Spending some time to think about design issues would help you in organizing your functions, methods, and classes. Before start coding, I would spend hours or a few days designing my function, method, or class. This process would include: * A meaningful name for the function, method, or class. * Document what that function, method or class does. This should include references to published work where appropriate. Remember that in a few weeks or months, you would likely forget what your code does. But people would still want to maintain your code. You code and write documentation in order to minimize the learning curve of people who would need to use your code, expand on it, or debug it. * Give a high level explanation of the algorithm you're using, not just the reference where one can read up on the algorithm. * Clearly explain both the input and output. * Write pseudo code to get a feel for the structure of the function, method or class. With proper designing, the name of your module (if you're going to write a separate module on some area of graph theory) would give an indication of its content. If you think that the graph theory functions you will implement would be within a narrow area of graph theory, you might want to consider making them into a separate module. Or better yet, figure out if you can organize those 10 to 20 functions into a number of modules, and put all of those specialized modules within a subdirectory. For example, when I first started on expanding the crypto stuff, I wanted to implemented a number of block functions. Man, there are dozens of them around these days. So I created a subdirectory under crypto called "block_cipher". I then implemented various block ciphers in different modules, organizing them under "sage/crypto/block_cipher". If people want to use those block ciphers, they can import them. > These may be questions to ask in several years... But Sage is growing pretty > quickly, though O_o A problem with open source software projects like Sage is a lack of reviewer time. There are about 100 tickets at the moment needing review, but people who are interested in getting them in don't have time to spare or don't have the necessary maths background to properly review. The upcoming review day next week should cut down on the number of tickets needing review. Small changes (a few new functions per ticket) are usually easier to review than big changes (a few new modules per ticket). In any case, feel free to ask more questions if you want clarification. Or am I missing the point you want to make? -- Regards Minh Van Nguyen --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
