Re: EOF bug?
Re: EOF bug?
- Subject: Re: EOF bug?
- From: "Morris, Mark" <email@hidden>
- Date: Mon, 13 Aug 2018 22:32:05 +0000
- Thread-topic: EOF bug?
Hi Samuel,
Thanks so much for the file!
Hopefully this doesn’t come across as pedantic, but I partially disagree with
your statement below. You should feel safe to reimplement basic functionality,
at least with Apple’s frameworks. Just for example, perhaps you would want to
subclass NSArray to implement a HighPerformanceArray, where maybe it switches
to a sparse array implementation when appropriate and/or does some sort of
Huffman encoding if the array gets above a certain size. The theory is that
don’t need to reimplement every method in NSArray, just the base methods that
access the fields directly. That’s what the list in the documentation is
supposed to tell you, and it’s not supposed to be a risky proposition.
Given that, though, they clearly messed up here. ;-)
Thank you again, and take care!
Regards,
Mark
From: Samuel Pelletier <email@hidden>
Date: Monday, August 13, 2018 at 2:27 PM
To: "Morris, Mark" <email@hidden>
Cc: "email@hidden" <email@hidden>
Subject: Re: EOF bug?
Mark,
objectsNoCopy() is declared in NSArray so all subclasses should have a working
implementation.
It is very risky to subclass and try to reimplement the basic functionality,you
need to make sure the subclass conform to all the superclass behaviour past,
present and future... Interface are there for multiple implementations
abstraction.
I attached my version of the java source to put in ERExtension in the
cone.webobjects.eoaccess package.
Regards,
Samuel
Le 13 août 2018 à 13:51, Morris, Mark
<email@hidden<mailto:email@hidden>> a écrit :
Just a little more info I discovered.
This appears to have hit a subtle implementation problem with NSMutableArray.
Its implementation of addObjectsFromArray() uses a protected method,
objectsNoCopy(), on the *argument* array, not on *this* array. That seems to me
to break the contract of “protected”. The argument array could be a different
subclass, with a different implementation, and, based on the documentation,
might not even implement objectsNoCopy().
So even if the writers of _EOExpressionArray had reimplemented NSMutableArray
as required by the documentation (which they didn’t), this bug would have still
surfaced due to the architecture issue in NSMutableArray’s implementation.
-- Mark
From: Webobjects-dev
<webobjects-dev-bounces+mark.morris=email@hidden<mailto:webobjects-dev-bounces+mark.morris=email@hidden>>
on behalf of "Morris, Mark"
<email@hidden<mailto:email@hidden>>
Date: Monday, August 13, 2018 at 12:30 PM
To: Samuel Pelletier <email@hidden<mailto:email@hidden>>
Cc: "email@hidden<mailto:email@hidden>"
<email@hidden<mailto:email@hidden>>
Subject: Re: 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<mailto:email@hidden>>
Date: Monday, August 13, 2018 at 12:09 PM
To: "Morris, Mark" <email@hidden<mailto:email@hidden>>
Cc: "email@hidden<mailto:email@hidden>"
<email@hidden<mailto: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