22 Nov
2007
22 Nov
'07
9:38 p.m.
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:
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.
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. 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.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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