22 Nov
2007
22 Nov
'07
1:25 a.m.
On (21/11/07 23:39), Adrian Kuhn wrote:
From: Adrian Kuhn <akuhn(a)gmx.ch>
To: Related to the development of Moose and other related tools
<moose-dev(a)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
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?
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.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev