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