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