Re: GDL2: prototypes and EOAttribute.m

[Fred Kiefer]

Hi Mark,

thank you for your patches. I tried to understand the last one before
integrating it and I am not completely convinced this is the best
solution. Could you please first provide a few tests that check the
expected behaviour? That way we could run the test against Apples EOF
and see if the behaviour there matches the tests and then adjust our
code to satisfy the tests.

With your latest change we would get values from the first prototype
even when we set a new one. At least in the case where the first had a
value and the second hasn't got one. This seems wrong to me.
Would it be sufficient to remove the line

      _flags.protoOverride = 0;

from setPrototype:?

Fred



Am 19.05.2017 um 23:35 schrieb Mark Clements:
> Addendum: -setPrototype:(EOAttribute *)prototype is defined in the API
> for EOF 4.0 and 4.5. A revised patch is attached which sets
> _flags.protoOverride and updates the propertyList at the start of
> -initWithPropertyList:owner. This replaces my patch from yesterday.
> 
> -- Mark
> 
> On 05/18/2017 10:50 PM, Mark Clements wrote:
>> Thanks for accepting my earlier patch on the GDL2 test suite.
>>
>> As a reminder, GDL2 has prototypes for different types of attributes:
>> the prototypes are used to set properties when those properties have not
>> already been specified for an attribute. The prototypes are specific to
>> an EOAdaptor. The current issue is that the properties are not being
>> updated from the prototypes.
>>
>> Under the EOAttribute class, -initWithPropertyList:owner calls
>> -setPrototype early, which sets _flags.protoOverride = 0 and then calls
>> -_updatePrototype, which carefully manipulates keys based on
>> _flags.protoOverride -- which has already been set to zero and therefore
>> does nothing (?). Interestingly, _flags.protoOverride is updated later
>> in -initWithPropertyList:owner -- but this all happens /after/
>> -setPrototype has been called with no other effects.
>>
>> As most of the remainder of -initWithPropertyList:owner uses
>> propertyList, one fix would be to update propertyList from the prototype
>> at -setPrototype. I have attached a draft patch that does this -- but is
>> this the right approach? Note that this is a more general solution to my
>> earlier patch. An alternative approach would be to call -setPrototype
>> late in -initWithPropertyList:owner.
>>
>> The patch increased the number of passed tests from 1033 to 1101.
>>
>> Kindly, Mark.
>>
>> On 05/14/2017 06:22 PM, Fred Kiefer wrote:
>>> Hi Mark,
>>>
>>> thank you very much for this fix on the gdl2 tests. I have applied this
>>> patch. The only thing I did change was instead of commenting out the
>>> TEST_EXCEPTION macros I replaced them with the newer PASS_EXCEPTION calls.
>>>
>>> Cheers,
>>> Fred
>>>
>>> Am 02.05.2017 um 07:49 schrieb Mark Clements:
>>>> I have now attached a diff file for these changes.
>>>>
>>>> Kindly, Mark.
>>>>
>>>> On 05/01/2017 11:25 PM, Mark Clements wrote:
>>>>> I have had a first attempt at getting the testsuite working with GDL2.
>>>>>
>>>>> It seems to have been a while since the GDL2 testsuite was updated (see
>>>>> patch below). Suggested changes include:
>>>>>  + Bug fixes on labelling
>>>>>  + Change -cString to -UTF8String
>>>>>  + Change sel_eq to sel_isEqual
>>>>>  + Change #include "../ObjectTesting.h" to #include "ObjectTesting.h"
>>>>>  + Change ADDITIONAL_NATIVE_LIBS+=EOControl EOAccess  to
>>>>> ADDITIONAL_NATIVE_LIBS+=EOAccess EOControl (?)
>>>>>  + Comment out TEST_EXCEPTION: is this still defined?
>>>>>
>>>>> This gave me 1031 passed tests, 10 failed sets, 9 failed tests and 5
>>>>> failed files.
>>>>>
>>>>> I was not certain whether the failed tests indicate that the Key Value
>>>>> Coding mechanism is broken. Any guidance on this point would be welcomed.
>>>>>
>>>>> Kindly, Mark.
>