20 Nov
2007
20 Nov
'07
4:30 p.m.
On 20 Nov 2007, at 15:52 , Stéphane Ducasse wrote:
Non-meta-programming-using-code :) sorry for the pun.
Take a group of instances, change them to same anonymous subclass and
attach a class var to that subclass. The plan is to use this for
entity's model backlink.
I discussed with Toon recently, he might gonna implement most of the
meta-programming when adapting the code-generation for Famix 3.
Yes, and publish them as HTML or Latex for API documentation, as
Lukas does for Pier et al.
Dasselbe in Grün, Fame is Meta's new name.
I can write some for Fame and other kernel-related tasks.
@Doru, could you do tutorials for UI-related tasks? I think you now
best which is part of Moose's public interface and which is private
stuff.
Smaller test fixtures are most critical, I'd say.
- __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 do not understand what is Java-like code? I was mainly thinking of (i) collective instance
variables for the
model backlink,
Sorry I do not know what is a collective instance variable (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).
so what can we do if we are normal people to help. I'm not sure that
I can help on this one. - 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
for doing what? Collecting the comments?
- CodeFoo.Task
What is it?
- 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)
Why do you change Meta? to FAME? - Sketch some
rough UML of moose main class structure
- FM3.MultivalueLink for many-to-many relationships
- Write tutorials for basic plugin-developer tasks
I would love to proofread that and do them. But I have a problem to
write one for now because moose changes too mcuh for me. - 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)
I'm not sure since I certainly wrote a lot of ugly tests that I can
cut them into meaningful - 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
I will check moose and see what I can do.
Stef