On May 13, 2011, at 2:49 PM, John Huss wrote:
> On Fri, May 13, 2011 at 1:38 PM, David Avendasora <[email protected]>
> 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.)
Dave
>
> John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
