21 Nov
2007
21 Nov
'07
11:01 p.m.
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.
Sure by breaking all the navigation and other tools.
I did some simple DNU tricks with roel and we got burnt by them after
a while
because the senders and implementers did not work anymore.
So the "easier" is still to be proven. This is why with Moose I
always tried not to put
my language research in.
When I see how difficult is to support something as simple as traits
at the level of the ide
I think that the Smalltalk image style is either getting in my way or
proving me that
beauty and small means something and that the IDE is just a mirror of
it.
AA
On 21 Nov 2007, at 14:03 , Stéphane Ducasse wrote:
for me that was expert in another life on meta
programming, I like to
keep meta programming
for the meta stuff. If at the end of the day you implement something
really cool but which alienates
the base programmers then you are wrong.
My fear is that once there too much magic in moose nobody will ever
dare to change it.
At this point of the story what will happen is that certainly someone
will just fork and rewrite something
that he can understand. So expect for really crucial I would
recommend against using reflection in the domain
code.
Stef
On 20 nov. 07, at 16:30, Adrian Kuhn wrote:
I can read beta tests that
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 20 Nov 2007, at 15:52 , Stéphane Ducasse
wrote:
I think that a good tutorial is much better because the approach of
comment
always start and never finished.
> - __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?
Non-meta-programming-using-code :) sorry for the pun.
> I was mainly thinking of (i) collective instance variables for the
> model backlink,
Sorry I do not know what is a collective instance variable
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.
> (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.
I discussed with Toon recently, he might gonna implement most of the
meta-programming when adapting the code-generation for Famix 3.
> - 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?
Yes, and publish them as HTML or Latex for API documentation, as
Lukas does for Pier et al. >
> - 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?
Dasselbe in Grün, Fame is Meta's new name.
> - 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.
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.
> - 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
Smaller test fixtures are most critical, I'd say.
> - 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev