Re: EOF bug?
Re: EOF bug?
- Subject: Re: EOF bug?
- From: "Morris, Mark" <email@hidden>
- Date: Mon, 13 Aug 2018 17:29:17 +0000
- Thread-topic: EOF bug?
Hi Samuel,
Yes, I considered suggesting the route of removing _array, but I was concerned
that they went that way for a reason, although I can’t imagine what that would
be. Like you said, it seems like a very odd choice.
Yes, we compile our Wonder frameworks, so the file would be great. Thanks for
looking into this!
Regards,
Mark
From: Samuel Pelletier <email@hidden>
Date: Monday, August 13, 2018 at 12:09 PM
To: "Morris, Mark" <email@hidden>
Cc: "email@hidden" <email@hidden>
Subject: Re: EOF bug?
Mark,
OK, I see, _EOExpressionArray is a very bad exemple of inheritance...
pretending to be a NSMutableArray but in fact using a NSMutableArray and
implement some parts of it.
I do not see an easy way to patch this except by adding another fixed
reimplemented class in ERExtensions.
I reimplemented it by removing the _array member and adjusting the Clone
method. Just adding the objectsNoCopy() will not solve other NSMutableArray
method mis behaviours.
Either the class is really a NSMutableArray or should not extend it and only
the implemented methods will exists. With the current situation where we do not
compile the WO frameworks, I think adjusting the hierarchy is not possible.
Here is my Clone method. All references to _array including methods that only
forwarded the call are removed.
public Object clone()
{
_EOExpressionArray aCopy = new _EOExpressionArray(_prefix, _infix, _suffix);
aCopy.addObjectsFromArray(this);
return aCopy;
}
Do you compile your wonder frameworks ? If you do, I will send you the java
file or you can create it yourself.
Regards,
Samuel
Le 13 août 2018 à 10:23, Morris, Mark
<email@hidden<mailto:email@hidden>> a écrit :
Hi Samuel,
Thanks for the response!
Sorry, it was a long night. The problem does indeed occur when objectsNoCopy()
returns null, even though there are objects in the EOExpressionArray. However,
the method directly in EOAttribute is actually addObjectsFromArray(), which
calls objectsNoCopy() in its implementation.
Regards,
Mark
From: Samuel Pelletier <email@hidden<mailto:email@hidden>>
Date: Monday, August 13, 2018 at 6:31 AM
To: "Morris, Mark" <email@hidden<mailto:email@hidden>>
Cc: "email@hidden<mailto:email@hidden>"
<email@hidden<mailto:email@hidden>>
Subject: Re: EOF bug?
Hi Mark,
I checked my version of EOAttribute and was unable find call to objectsNoCopy()
in the code. I checked the WO and ERAttributeExtension versions of the class.
Are you on an older version of WO ?
Samuel
Le 13 août 2018 à 05:32, Morris, Mark
<email@hidden<mailto:email@hidden>> a écrit :
Hi all,
After much time and effort, I’ve traced a problem in my code to what appears to
be a bug in EOF’s _EOExpressionArray.
Let me state first that we’re way behind in our Wonder version, so it’s
possible that Wonder has fixed this already, but a quick search didn’t find it.
(We’re planning to catch up to current in the next few months.)
The problem seems to stem from the fact that _EOExpressionArray extends
NSMutableArray, but it doesn’t reimplement objectsNoCopy(). This is a problem,
because _EOExpressionArray uses it’s own internal array, not the superclass’s.
There’s a critical point in EOAttribute._normalizeDefinitionPath() where
objectsNoCopy() is called but returns null, even though the _EOExpressionArray
has elements, because it’s referencing the superclass array instead of the one
local to _EOExpressionArray.
Has anyone seen this? Has it been patched? Thanks!
Regards,
Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list
(email@hidden<mailto:email@hidden>)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden<mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden