On 17 Nov 2007, at 0:34 , Adrian Kuhn wrote:
The tracker seems to be down, I can not acces the list. I will ask marcus how to fix this, as he uses the same for reflectivity.
There are tons of small issues that I do not remember par coeur. But I will try to collect some major issues I remember in a follow up mail.
- __state__ is the main abandoned construction site (the idea there is to considerable recue the memory footprint of moose and trade-off performance in the same time. I stopped mid way, when all my suggestion to use meta-programming got rejected as I dont think we can reduce the memory-footprint with Java-like code as it is now. I was mainly thinking of (i) collective instance variables for the model backlink, (ii) dynamic instance variables (ie wide classes) for all none FAMIX.Core properties and metrics, adn (iii) collective behavior for collective behavior. In particular the (i) would in addition to saved instvar slots also save the need to keep all those ugly caches of all-entities-of-one-kind in the model).
- Write method comments
- New exception dialog that shows a form for bug-repot and "send to moose-dev" button which will take report, attached stack trace and other interesting info and send it to this list.
- Have some Javadoc like comment tool
- CodeFoo.Task
- Write package comments
- Switch from Meta to Fame (the new Famix 3.0 Meta on which I started working on today's 15 hour odyssee through France, Belgium and Germany) (Fame stands for FAmix MEtamodel)
- Sketch some rough UML of moose main class structure
- FM3.MultivalueLink for many-to-many relationships
- Write tutorials for basic plugin-developer tasks
- Proper test setup - (currently they are too long, and their fixture too complexe to be a help. When broken the single point of failure is not evident) - (as a first step, this can mean as little as making two test suites, one with the small and okay tests, and one with the ugly tests) - (I expect that each ugly tests could be splitted in at least two dozen nice tests each )
- Write class comments
- Tagging of Moose's public interface with a pragma and setup a way to check at runtime if plugins violate this constraint
- Propose nice coding conventions and useful best practices for Moose
- Enforce them
That is all I remember now. For priorities, all of that is low to very low on my list except for supporting the transition from F2.2 to F3
AA