[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 22 Mar 2003 14:14:37 +0100 (CET)
On Sat, 22 Mar 2003 10:46:50 +0100 Stéphane Corthésy <address@hidden> wrote:
>| Mea culpa, my fault, désolé.
Nobody died so it's not too serious.
I was just a little annoyed and nervous because I've spent many days to fix 2
memory bugs, all things were working very
well and suddently after updating the whole thing was crashing on many points
>| I did that stupid patch, and didn't realize how stupid it was until I
>| really needed what was (previously) in EOGenericRecord. I shouldn't
>| have had to disable the implementation of KVC in EOGenericRecord, as we
>| also need it on OSX. In fact, in the (modified) sources I posted on our
>| website last week I already had reenabled (partially) the KVC for
>| EOGenericRecord, and corrected some (real) problems in it (recursive
>| I'll check now your new version and see whether it still works on OSX.
It's also my fault as there's no doc on GenericRecord KVC.
EOGenericRecord introduce a search on it's dictionary after searching for
_set/_get selector but BEFORE searching for
get/set selector. That's why we can't use base methods. And IMHO, using
handleQueryWithUnboundKey is anyway not a good
thing to handle dictionary search because in this case, nobody can use class
derived from GenericReecord to implement
specific code to handle really not found keys.
I'm not entirely satisfied on how KVC was coded in EOGenricRecord because of
code duplication but it was what we've
found as the 'best solution' last year after long discussions.
Testing modification with debug mode raise more possible problems (loops)
because there's more log of object
Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement - 93200 Saint-Denis - France
Tel: +33 1 4940 0999 - Fax: +33 1 4940 0998