On 17 Nov 2007, at 0:34 , Adrian Kuhn wrote: - __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

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.

I know, and I dont agree :) My proposals would make Moose easier to understand and easier to maintain, even for the so-called base programmers. In addition, there would be less code, less memory footprint and thus more performance. AA On 21 Nov 2007, at 14:03 , Stéphane Ducasse wrote:

There is no DNU in what I propose. I sent out a long mail explaining everything some time ago, I will try again Instead of E1 >> attr ^ attr E1 >> attr: anObject ^ attr := anObject you as base programmer will write E1 >> attr ^self wideVarAt: #attr ifAbsentr: [ nil ] E1 >> attr: anObject self wideVarAt: #attr put: anObject and the wide classes implementation does all the magic for you. The same for the collective state, instead of E2 >> parent ^parent E2 >> parent: anObject parent := anObject you as base programmer will write E2 >> parent ^self groupVarAt: #parent ifAbsentr: [ nil ] E2 >> parent: anObject ^self groupVarAt: #parent put: anObject and the collective state implementation will again do all the magic for you. This is certainly no more complex than writing something like E3 >> attr ^dict at: #attr ifAbsentr: [ nil ] E3 >> attr: anObject ^dict at: #attr put: anObject and let the Dictionary implementation do all the magic for you. In all three cases, E3 as well as E2 and E1, all refactorings, renamings, all senders of, implementers of and whatever you might dream of your business code will still work. It will be the only change to any client code in Moose or any plugin (assumed you did you homework, using e isKindOf: E and not e class == E for type checking). All instances of E3, E2 and E1 are inspectable, the code of all three classes, E3, E2 and E1 is browseable, storeable, refactorable, understandable, maintainable etc pp.

On 22 Nov 2007, at 1:25 , Toon Verwaest wrote: Same as for the dictionary example below, it is requieres human decision to decide which attributes should be implemented as instvar, which using a dictionary and which using wide classes/dynamic instvars or collective state. The compiler can and should not take such decisions. AA

Adrian I think also that wideclasses have an impact on the classBuilder so it would be nice to have a separate packages dealing with such issue. After a while I would be interested to port it to squeak. But first I guess that we want to be convinced for the idea. I was not thinking about wideclass because you change the class of the object in the background. I would prefer a class that has hasTable ivs in addition to named one. It would be completementary with VariableSubclass Stef On 22 nov. 07, at 13:45, Stéphane Ducasse wrote:

But Adrain can you listen when people say something. Why do you need to change the class and have wideclasses (besides for the fun of it) versus having classes supporting attributes based on key: FamixEntity HashTableSubclass instanceVariableNames: 'name date' FamixEntity>> bar .... foo .... =means that you can access a key based variable FamixEntity>> blbabl: aValue ...... foo := aKey .... measn that you can change the vaue of keyed variable. And of course that different instance can have different key and value. But I'm really not convinced by wideclasses, because you will have to define several classes and migrate on the fly instances between them. I also think that wide classes are angerous because you as a programmer may not know to which subclasses superclass to migrate. Then what do you do of the state.... (Fred rivard did his PhD on that). So there is a DIFFERENCE between wideclass and having keybased iv and I think that moose would gain in keybased iv even if the __state__ looks ok for me now since it is a good compromise. Stef On 22 nov. 07, at 22:33, Adrian Kuhn wrote:

Yes this is what I was thinking too. And also the fact that I have to specify the widening as a programmer. On 23 nov. 07, at 15:34, Adrian Kuhn wrote:

On 22 Nov 2007, at 15:07 , Bergel, Alexandre wrote: Genau! you are right. What I propose is a kind of Javadoc-like tool to encourage commenting. AA

Hi, I believe that here there are two points under discussion, each with 2 subpoints: A1) the reasons for wide classes A2) the solutions for wide classes B1) the reasons for collective behavior B2) the solutions for collective behavior I propose to talk about each of these two points individually, because they are not the same to me. Doru On Nov 22, 2007, at 8:37 PM, Orla Greevy wrote: -- www.tudorgirba.com www.tudorgirba.com/blog "The coherence of a trip is given by the clearness of the goal."

why F would be only 80 bytes? you have superclass, subclass, format, methodDict + methods inside (it does not have to have a metaclass) but may be you need it. On 22 nov. 07, at 23:13, Adrian Kuhn wrote:

ok I do not remember but in objectmemory there is method that retrun the size of an object (someone told me that it was a bit borken) I do not remember its name stef On 23 nov. 07, at 15:30, Adrian Kuhn wrote: