• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: More Readable EOQualifiers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More Readable EOQualifiers


  • Subject: Re: More Readable EOQualifiers
  • From: Ramsey Gurley <email@hidden>
  • Date: Fri, 13 May 2011 13:44:10 -0700


On May 13, 2011, at 1:09 PM, David Avendasora wrote:


On May 13, 2011, at 2:49 PM, John Huss wrote:

On Fri, May 13, 2011 at 1:38 PM, David Avendasora <email@hidden> wrote:
My new strategy combines still doing some setup, but the setup is explicitly for making things easier to read.

EOQualifier haveRedHair = Student.HAIR_COLOR.eq(MyAppConstants.RED_HAIR);
EOQualifier areActive = Student.IS_ACTIVE.isTrue();
NSArray redheadedStudents = mySchool().students(Student.that(haveRedHair).and(areActive));
The thing is, the code only reads like english IF you save the qualifier to a temporary variable AND name it appropriately; that's too loose of a constraint.  

Well, I wasn't meaning that using it would be enforced in any way.

But I do agree that it only reads well if you jump through the other hoops. It's just that in the past, you _couldn't_ make it read like English. This is about enablement, not enforcement.

I know that I often times have a hard time parsing my own qualifiers, let alone the ones written by others once they get longer than two chained together. I work on a team of 6 WO developers. Some of whom go back to Cocoa WO days and some come from a J2EE background. Everyone has a slightly different take on how to write qualifiers and since the projects have been around for years (pre ERXKey) the variety of ways that a qualifier can be expressed is astounding. They all make sense, after a while, but I'm trying to come up with a dead-obvious syntax that is easy to implement so everyone feels able and comfortable with updating things to more modern methods.

When combined with automatic code formatting (using save actions in eclipse), you can get some very nicely formatted, easy to read code that is obvious as to what it is doing. Sprinkle in a little commenting and it's even more me-proof.

 A more real-world example from the project I came up with the "that" method for:

public static final Group returningHSLearningCoach(EOEditingContext editingContext) {
    Group group = Group.fetchRequiredGroup(editingContext, // EOEditingContext editingContext
                                           Group.that(isActive())
                                                .and(isForRegisteringStudents())
                                                .and(isForHighSchoolStudents())
                                                .and(isForASurveyTakenByTheLearningCoach())
                                                .and(isAboutTheLearningCoaches())
                                                .and(isAboutTheStudent()),
                                           true, // boolean usesDistinct
                                           null, // String prefetchingKeyPaths
                                           false); // boolean refreshesRefetchedObjects
    return group;
}

So I would agree with Ramsey that the shorter, non-english version is sufficient.  I'm not opposed to adding it, but I probably wouldn't use it.

I guess I missed Ramsey's implementation of how he got his first qualifier to be chainable.

I'll generally do it like

Student.HAIR_COLOR.eq(HairColor.RED).and(Student.IS_ACTIVE.isTrue());

If it gets really long, I'll break lines where the and/or/not's are located and indent to make them easier to comprehend.

Even if I just had a bunch of EOQualifiers, as in your example above, there's always ERXQ.and()

ERXQ.and(isActive(),
isForRegisteringStudents(),
isForHighSchoolStudents(),
isForASurveyTakenByTheLearningCoach(),
isAboutTheLearningCoaches(),
isAboutTheStudent())

Ramsey


As for generating them in the templates I don't think it's worth it.  I would take less time to declare a constant with the qualifier than to add it to the model somehow.

I think for booleans and things that are obvious as to what the possible values are it can be worth it as that's less code for me to create bugs with. However, there's not a whole lot of those. (useful places to do this, not my bugs. There's _lots_ of those.)

Dave


John


 _______________________________________________
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

References: 
 >More Readable EOQualifiers (From: David Avendasora <email@hidden>)
 >Re: More Readable EOQualifiers (From: Chuck Hill <email@hidden>)
 >Re: More Readable EOQualifiers (From: David Avendasora <email@hidden>)
 >Re: More Readable EOQualifiers (From: John Huss <email@hidden>)
 >Re: More Readable EOQualifiers (From: David Avendasora <email@hidden>)

  • Prev by Date: Re: More Readable EOQualifiers
  • Next by Date: How to use dates
  • Previous by thread: Re: More Readable EOQualifiers
  • Next by thread: Re: More Readable EOQualifiers
  • Index(es):
    • Date
    • Thread