> On Apr 26, 2015, at 3:53 AM, Paul Hoadley <pa...@logicsquad.net> wrote: > >> I actually named my qualifier ERXQualifierExistsSubquery as it is a peer of >> ERXQualifierInSubquery. My plan is to deprecate ERXExistsQualifier as I >> think the re-implementation of the "in" subquery functionality in >> ERXExistsQualifier was well-intentioned, but ultimately a mistake. > > Ah, OK. Cool. FWIW, I think that’s a great idea. So the short answer is > no, it’s not a drop-in replacement, but it also won’t break anything anyone’s > currently doing (other than flagging the use of a to-be-deprecated class) > because you’re not touching the current ERXExistsQualifier.
I *am* changing what qualifier is returned by ERXKey#containsAnyObjectSatisfying(EOQualifier), ERXKey#isEmptyRelationship(), etc. These should not cause any functional difference, but will cause a compile-time exception if the code is expecting an ERXExistsQualifier as they will now return an ERXQualifierExistsSubquery instead. I will also try to make the reason for deprecation clear in the ERXExistsQualifier documentation and by also throwing exceptions in the situations where any now-deprecated use of ERXExistsQualifier is going to fail. That way any code that is currently broken will inform the developer of what went wrong and how to fix it (i.e., what non-deprecated qualifier to use). Dave
_______________________________________________ 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
