Common monkey modules
Monkey Forums/Monkey Programming/Common monkey modules
| ||
| After a short discussions ( http://www.monkeycoder.co.nz/Community/posts.php?topic=1174 ) there was an idea to create some common modules for Monkey, and combine them into one package. Common Module - it's a module that can have only one implementation. For example json, database, regexp, xml, http, ftp, etc. This package is designed for reducing the fragmentation of modules for Monkey. For example right now I already know about three modules that open browser by default... If we joined forces and did not do the same thing separately, it would get better performance. Right now I'm not sure that it will be interesting to someone exept for me, so I would like to hear your opinion. List of planned modules: system (system info: RAM, CPU etc.), datetime (date and time functions), GUI (gui wrapper for standart elements), database, regexp, json, xml, http, ftp, string (additional functions for string, for example, format), network (network utils), device (functions for portable devices) I'm not bad in programming for HTML5 and Android, but other targets are almost unknown for me, so so I'm counting on your help in developing for other targets. I would also like to discuss jointly the design of future modules, but I think it will be easier to do it inside the team, if it gathers together:) I've created an organization on github - https://github.com/MonkeyModules Why git? In my opinion this system is much faster, more convenient than svn and mercurial (especially in terms of operations with branches), and more dynamic project than google code. But in case of need mirrors of the other open-source hosting will be created. Write your suggestions, comments and criticism. Everything will be taken into account. If you're ready to take part in the project - Sign up for github (if not already registered) and send your nickname on - commonkeymod [at] gmail.com or private message on github and I'll invite you into the organization. |
| ||
| this website needs a code archive area like the blitzmax site |
| ||
| I can't say I'm a fan of the idea of developing a big glob of modules as wide-ranging as those suggested as a single project. There's nothing stopping people curating a module collection if they want, of course, I'm just not keen on being part of something that amorphous from a development perspective. I also simply disagree with the idea of having canonical implementations. If you look at other language communities there's healthy competition and cross-fertilisation of things like HTML parsers or UI libraries. What would be useful, over and above the module registry or an archive area, would be to get a module manager up and running like ruby gems. |
| ||
| Hi, I'm not sure about the whole 'package' idea. What would be the point? Instead, I reckon you should just work on a bunch of 'top level' modules, and try to make them as stand alone as possible so that they can be integrated easily with other modules. Otherwise, I think you'll be in danger of ending up with a large, klunky 'super system'. This seems to be how Python and Perl have achieved such a huge number of modules - Perl in particular has something like 1000 'top level' modules I think! There'll all relatively small and stand alone with few dependencies, so they're easy to reuse. And I also agree with muddy_shoes that having multiple modules doing similar things isn't necessarily a bad thing. For example, support for multiple GUIs, fast vs accurate XML parsers etc. And these projects can feed off each other too. I'd actually quite like to add the dom and os modules to a repos sometime soon so that people could tweak them. I'd still 'own' them in that I could reject edits etc, but you can always fork! How does that sound? You'd just need to change the repos into a plain 'monkey modules' repos! |
| ||
| I'm all up for monkey modules on git. Huge number of small modules would be my preferred approach. |
| ||
| I have another idea, Why don't we ask Mark to have a code archives section in this site, with an option to rate the code contributions? |
| ||
| Because git would allow collaborative development and updates loads more easily. |
| ||
| And now there's GitHub for Mac http://mac.github.com/ :-) (Just downloaded) |
| ||
| I'm for independent modules. Cross-fertilisation is the way to go. Users can always make up their own module collections that incorporate the ones they generally find useful. |
| ||
| @marksibly if I understand correctly, it sounds great! The only reason why I wanted to unite everything in one package is to leave free common names of the modules. But it seems that now it's not necessary. I renamed the organization plain MonkeyModules. I'm also very glad that os and dom module forks will be part of MonkeyModules and it will be developed jointly. Thank you! @muddy_shoes I also agree with you. Of course you can implement differently support of, for example, xml or json. But I think it makes sense only when we get a fundamentally different module. As Mark said: "fast vs accurate XML parsers etc." If as a result there are two absolutely identical modules, but written by different people, in this case I think it would be useful to these two people unite efforts. @ziggy, I believe that code archives section should also be on the site, but in order to publish some small snippets of code, for example, some tips and tricks |
   |