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 <sam...@samkar.com> Date: Monday, August 13, 2018 at 2:27 PM To: "Morris, Mark" <mark.mor...@experian.com> Cc: "webobjects-dev@lists.apple.com" <webobjects-dev@lists.apple.com> 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 <mark.mor...@experian.com<mailto:mark.mor...@experian.com>> 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=experian....@lists.apple.com<mailto:webobjects-dev-bounces+mark.morris=experian....@lists.apple.com>> on behalf of "Morris, Mark" <mark.mor...@experian.com<mailto:mark.mor...@experian.com>> Date: Monday, August 13, 2018 at 12:30 PM To: Samuel Pelletier <sam...@samkar.com<mailto:sam...@samkar.com>> Cc: "webobjects-dev@lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev@lists.apple.com<mailto:webobjects-dev@lists.apple.com>> 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 <sam...@samkar.com<mailto:sam...@samkar.com>> Date: Monday, August 13, 2018 at 12:09 PM To: "Morris, Mark" <mark.mor...@experian.com<mailto:mark.mor...@experian.com>> Cc: "webobjects-dev@lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev@lists.apple.com<mailto:webobjects-dev@lists.apple.com>> 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 <mark.mor...@experian.com<mailto:mark.mor...@experian.com>> 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 <sam...@samkar.com<mailto:sam...@samkar.com>> Date: Monday, August 13, 2018 at 6:31 AM To: "Morris, Mark" <mark.mor...@experian.com<mailto:mark.mor...@experian.com>> Cc: "webobjects-dev@lists.apple.com<mailto:webobjects-dev@lists.apple.com>" <webobjects-dev@lists.apple.com<mailto:webobjects-dev@lists.apple.com>> 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 <mark.mor...@experian.com<mailto:mark.mor...@experian.com>> 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 (Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_webobjects-2Ddev_samuel-2540samkar.com&d=DwMFaQ&c=BNNF-YNv0CLLslhP2Bcx5Q&r=R0ZqsewJs3eSJk7vLCqZv0r5kJlLXQLnGTeg9t8MlqA&m=AdvAfKTkUyccvBpaKhr9GvlfY3653NxMU8J5XO6ue2A&s=yDB_Rzh491N9j7il8RMpWcTkZo6Q_-nHy8gitXhx_28&e=> This email sent to sam...@samkar.com<mailto:sam...@samkar.com>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
