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