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 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.
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
