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.
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.)