Hi
I would like to give a try to do something else than latex. Is there a list of bugs that I can work on?
Adrian you mentioned __state__ to finish and I know that Task was left not totally finished. Could you put your todo with the probability that you will work on them?
Stef
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.
AA
On 16 Nov 2007, at 11:15 , stephane ducasse wrote:
Hi
I would like to give a try to do something else than latex. Is there a list of bugs that I can work on?
Adrian you mentioned __state__ to finish and I know that Task was left not totally finished. Could you put your todo with the probability that you will work on them?
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
Hi adrian
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 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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 20 Nov 2007, at 15:52 , Stéphane Ducasse 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 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
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:
On 20 Nov 2007, at 15:52 , Stéphane Ducasse 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 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.
I think that a good tutorial is much better because the approach of comment always start and never finished.
- 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.
I can read beta tests that
- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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:
On 20 Nov 2007, at 15:52 , Stéphane Ducasse 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 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.
I think that a good tutorial is much better because the approach of comment always start and never finished.
- 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.
I can read beta tests that
- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
On 20 Nov 2007, at 15:52 , Stéphane Ducasse 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 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.
I think that a good tutorial is much better because the approach of comment always start and never finished.
- 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.
I can read beta tests that
- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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.
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.
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.
On (21/11/07 23:39), Adrian Kuhn wrote:
From: Adrian Kuhn akuhn@gmx.ch To: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch Subject: [Moose-dev] Re: Could I get a list of bugs to smash in moose? Date: Wed, 21 Nov 2007 23:39:13 +0100
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.
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
Can't you just collect all such getters and seters and replace them by the widevar version at compilation time or something (or run some optimization over a set of compiled classes), as such that the "base programmers" don't have to worry about it? Should be quite easy to just detect getters and setters?
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.
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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 22 Nov 2007, at 1:25 , Toon Verwaest wrote:
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
Can't you just collect all such getters and seters and replace them by the widevar version at compilation time or something (or run some optimization over a set of compiled classes), as such that the "base programmers" don't have to worry about it? Should be quite easy to just detect getters and setters?
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
I was thinking over lunch about the following:
- do an implementation of "variableHashTableSubclass" so that any instance of such a class can get attribute - make sure that the tools are working especially senders, implementers, reference - give a try.
On 21 nov. 07, at 23:39, Adrian Kuhn wrote:
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.
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.
In squeak typically
self dictAt: #hkjhkj
was not showing the method when you queried for the references to #hkjhkj so I let imagine the pain to change that kind of code.
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.
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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
I was thinking over lunch about the following:
- do an implementation of "variableHashTableSubclass" so that any
instance of such a class can get attribute
- make sure that the tools are working especially senders,
implementers, reference
- give a try.
On 21 nov. 07, at 23:39, Adrian Kuhn wrote:
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.
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.
In squeak typically
self dictAt: #hkjhkj
was not showing the method when you queried for the references to #hkjhkj so I let imagine the pain to change that kind of code.
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.
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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Okay, I'll do a spike prototype and apply it on Moose in a image (as branching on Store is nothing advisable, alas). Wide classes might be more difficult to do in Squeak, as Array is not allow for changeClassTo:.
AA
On 22 Nov 2007, at 21:38 , Stéphane Ducasse wrote:
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:
I was thinking over lunch about the following:
- do an implementation of "variableHashTableSubclass" so that any
instance of such a class can get attribute
- make sure that the tools are working especially senders,
implementers, reference
- give a try.
On 21 nov. 07, at 23:39, Adrian Kuhn wrote:
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.
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.
In squeak typically
self dictAt: #hkjhkj
was not showing the method when you queried for the references to #hkjhkj so I let imagine the pain to change that kind of code.
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.
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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
Okay, I'll do a spike prototype and apply it on Moose in a image (as branching on Store is nothing advisable, alas). Wide classes might be more difficult to do in Squeak, as Array is not allow for changeClassTo:.
AA
On 22 Nov 2007, at 21:38 , Stéphane Ducasse wrote:
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:
I was thinking over lunch about the following:
- do an implementation of "variableHashTableSubclass" so that any
instance of such a class can get attribute
- make sure that the tools are working especially senders,
implementers, reference
- give a try.
On 21 nov. 07, at 23:39, Adrian Kuhn wrote:
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.
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.
In squeak typically
self dictAt: #hkjhkj
was not showing the method when you queried for the references to #hkjhkj so I let imagine the pain to change that kind of code.
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.
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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 23 Nov 2007, at 8:55 , Stéphane Ducasse wrote:
But I'm really not convinced by wideclasses, because you will have to define several classes and migrate on the fly instances between them.
Also, when "widening" is done one inst var by the other, there are ( n! ) possible subclasses for a class with ( n ) dynamic instance variables. We would have to define working sets there, so maybe __state__ is quite okay for the moment.
AA
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 23 Nov 2007, at 8:55 , Stéphane Ducasse wrote:
But I'm really not convinced by wideclasses, because you will have to define several classes and migrate on the fly instances between them.
Also, when "widening" is done one inst var by the other, there are ( n! ) possible subclasses for a class with ( n ) dynamic instance variables. We would have to define working sets there, so maybe __state__ is quite okay for the moment.
AA _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Since I just started to work with Moose, here are my few comments.
Instead of
E1 >> attr ^ attr E1 >> attr: anObject ^ attr := anObject
I understand the two methods above.
you as base programmer will write
E1 >> attr ^self wideVarAt: #attr ifAbsentr: [ nil ] E1 >> attr: anObject self wideVarAt: #attr put: anObject
I do not understand them. I guess that wide classes is somehow related to collective behavior?
The same for the collective state, instead of
E2 >> parent ^parent E2 >> parent: anObject parent := anObject
Those two methods are easy to understand.
you as base programmer will write
E2 >> parent ^self groupVarAt: #parent ifAbsentr: [ nil ] E2 >> parent: anObject ^self groupVarAt: #parent put: anObject
I do not understand them.
I am now diving into moose. Adding more comments on classes and methods will probably help more newcomers than adding wide classes/ collective behavior. I am maybe wrong, but this is the problem I am now facing.
my 2 pesos
Cheers Alexandre
On 22 Nov 2007, at 15:07 , Bergel, Alexandre wrote:
I am now diving into moose. Adding more comments on classes and methods will probably help more newcomers than adding wide classes/ collective behavior. I am maybe wrong, but this is the problem I am now facing.
Genau! you are right.
What I propose is a kind of Javadoc-like tool to encourage commenting.
AA
Hi,
I have not looked at Moose for a couple of months and I have to say I agree that from the examples here the new moose will be more difficult to understand. I think we should maybe take the time to provide everyone with the background and motivation behind the latest changes so that everyone feels comfortable about contributing to moose. It would be very sad if it turns into a geek only system.
My 1$ :-)
Orla
On Nov 22, 2007, at 3:07 PM, Bergel, Alexandre wrote:
Since I just started to work with Moose, here are my few comments.
Instead of
E1 >> attr ^ attr E1 >> attr: anObject ^ attr := anObject
I understand the two methods above.
you as base programmer will write
E1 >> attr ^self wideVarAt: #attr ifAbsentr: [ nil ] E1 >> attr: anObject self wideVarAt: #attr put: anObject
I do not understand them. I guess that wide classes is somehow related to collective behavior?
The same for the collective state, instead of
E2 >> parent ^parent E2 >> parent: anObject parent := anObject
Those two methods are easy to understand.
you as base programmer will write
E2 >> parent ^self groupVarAt: #parent ifAbsentr: [ nil ] E2 >> parent: anObject ^self groupVarAt: #parent put: anObject
I do not understand them.
I am now diving into moose. Adding more comments on classes and methods will probably help more newcomers than adding wide classes/ collective behavior. I am maybe wrong, but this is the problem I am now facing.
my 2 pesos
Cheers Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
Hi,
I have not looked at Moose for a couple of months and I have to say I agree that from the examples here the new moose will be more difficult to understand. I think we should maybe take the time to provide everyone with the background and motivation behind the latest changes so that everyone feels comfortable about contributing to moose. It would be very sad if it turns into a geek only system.
My 1$ :-)
Orla
On Nov 22, 2007, at 3:07 PM, Bergel, Alexandre wrote:
Since I just started to work with Moose, here are my few comments.
Instead of
E1 >> attr ^ attr E1 >> attr: anObject ^ attr := anObject
I understand the two methods above.
you as base programmer will write
E1 >> attr ^self wideVarAt: #attr ifAbsentr: [ nil ] E1 >> attr: anObject self wideVarAt: #attr put: anObject
I do not understand them. I guess that wide classes is somehow related to collective behavior?
The same for the collective state, instead of
E2 >> parent ^parent E2 >> parent: anObject parent := anObject
Those two methods are easy to understand.
you as base programmer will write
E2 >> parent ^self groupVarAt: #parent ifAbsentr: [ nil ] E2 >> parent: anObject ^self groupVarAt: #parent put: anObject
I do not understand them.
I am now diving into moose. Adding more comments on classes and methods will probably help more newcomers than adding wide classes/ collective behavior. I am maybe wrong, but this is the problem I am now facing.
my 2 pesos
Cheers Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"The coherence of a trip is given by the clearness of the goal."
On 22 Nov 2007, at 22:39 , Tudor Girba wrote:
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
To save memory.
Each moose element has a back pointer to its model. This is 4 byte per element, ie 4 MB per 1 Mio elements. Which are realistic maybe even low numbers when analysing histories or traces. With collective behavior the memory footprint is (4 + F) * M * T, where F is the size of an anonymous class, M is the number of models and T is the number of element types used per model. Given that F is about 80 byte (including object headers and metaclasses etc pp) and T maybe about 25, that is 2 KB = 0.002 MB per Model.
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.
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:
On 22 Nov 2007, at 22:39 , Tudor Girba wrote:
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
To save memory.
Each moose element has a back pointer to its model. This is 4 byte per element, ie 4 MB per 1 Mio elements. Which are realistic maybe even low numbers when analysing histories or traces. With collective behavior the memory footprint is (4 + F) * M * T, where F is the size of an anonymous class, M is the number of models and T is the number of element types used per model. Given that F is about 80 byte (including object headers and metaclasses etc pp) and T maybe about 25, that is 2 KB = 0.002 MB per Model.
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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
That is an empirical value, I created 1 Mio anonymous classes and profiled memory footprint.
Exact value was 82.4568027 (which does not make sense as its not modulo 4).
AA
On 23 Nov 2007, at 8:58 , Stéphane Ducasse wrote:
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:
On 22 Nov 2007, at 22:39 , Tudor Girba wrote:
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
To save memory.
Each moose element has a back pointer to its model. This is 4 byte per element, ie 4 MB per 1 Mio elements. Which are realistic maybe even low numbers when analysing histories or traces. With collective behavior the memory footprint is (4 + F) * M * T, where F is the size of an anonymous class, M is the number of models and T is the number of element types used per model. Given that F is about 80 byte (including object headers and metaclasses etc pp) and T maybe about 25, that is 2 KB = 0.002 MB per Model.
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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
That is an empirical value, I created 1 Mio anonymous classes and profiled memory footprint.
Exact value was 82.4568027 (which does not make sense as its not modulo 4).
AA
On 23 Nov 2007, at 8:58 , Stéphane Ducasse wrote:
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:
On 22 Nov 2007, at 22:39 , Tudor Girba wrote:
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
To save memory.
Each moose element has a back pointer to its model. This is 4 byte per element, ie 4 MB per 1 Mio elements. Which are realistic maybe even low numbers when analysing histories or traces. With collective behavior the memory footprint is (4 + F) * M * T, where F is the size of an anonymous class, M is the number of models and T is the number of element types used per model. Given that F is about 80 byte (including object headers and metaclasses etc pp) and T maybe about 25, that is 2 KB = 0.002 MB per Model.
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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
please talk about wide classes and key-based access class ivs there are different.
On 22 nov. 07, at 22:39, Tudor Girba wrote:
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:
Hi,
I have not looked at Moose for a couple of months and I have to say I agree that from the examples here the new moose will be more difficult to understand. I think we should maybe take the time to provide everyone with the background and motivation behind the latest changes so that everyone feels comfortable about contributing to moose. It would be very sad if it turns into a geek only system.
My 1$ :-)
Orla
On Nov 22, 2007, at 3:07 PM, Bergel, Alexandre wrote:
Since I just started to work with Moose, here are my few comments.
Instead of
E1 >> attr ^ attr E1 >> attr: anObject ^ attr := anObject
I understand the two methods above.
you as base programmer will write
E1 >> attr ^self wideVarAt: #attr ifAbsentr: [ nil ] E1 >> attr: anObject self wideVarAt: #attr put: anObject
I do not understand them. I guess that wide classes is somehow related to collective behavior?
The same for the collective state, instead of
E2 >> parent ^parent E2 >> parent: anObject parent := anObject
Those two methods are easy to understand.
you as base programmer will write
E2 >> parent ^self groupVarAt: #parent ifAbsentr: [ nil ] E2 >> parent: anObject ^self groupVarAt: #parent put: anObject
I do not understand them.
I am now diving into moose. Adding more comments on classes and methods will probably help more newcomers than adding wide classes/ collective behavior. I am maybe wrong, but this is the problem I am now facing.
my 2 pesos
Cheers Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"The coherence of a trip is given by the clearness of the goal."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Adrian Kuhn -
Bergel, Alexandre -
Orla Greevy -
stephane ducasse -
Stéphane Ducasse -
Toon Verwaest -
Tudor Girba