redefining a prototype derived from Association

[Brian Rice]

This is now fixed. I was using = to compare the traitsWindow 
delegateValues Arrays, which recursed into calling = on each element, 
which are traits, not regular objects, and so the error. So I modified 
addPrototype:derived: to perform the traversal itself and bootstrapped 
and tested it.

(In the process, I found that the Association =/hash methods were 
missing. They've been re-added.)

All of this, including fresh images, is available in the main and alpha 
repositories. Enjoy!

On Mar 15, 2005, at 1:41 PM, Brian Rice wrote:

> That's interesting. Basically addPrototype:derived: trying to call = 
> between the two traitsWindows (one, of the foo, two of the potentially 
> new foo). It shouldn't come up with the Association comparison method 
> (which starts by looking for a key to compare with), but I'll keep 
> digging further.
>
> It shouldn't matter which build you're using, as this code hasn't 
> changed much recently. Thanks for reporting this and I'll get back 
> when I have it figured out or fixed.
>
> On Mar 15, 2005, at 1:28 PM, Daniel John Crowe wrote:
>
>> Hi,
>>
>> When I do the following:
>> addPrototype: #foo derivedFrom: { Association }.
>> addPrototype: #foo derivedFrom: { Association }.
>>
>> I get an MNF on the second line for a missing selector #key, on a 
>> Cloneable object.  (Sorry I can't get a paste of this for you)
>>
>> However, the code works ok for:
>> addPrototype: #foo.
>> addPrototype: #foo.
>>
>> I'm not sure which build I'm using, I think it is post 0.3.2.
>>
>> Thanks,
>>   Daniel Crowe
--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/