Apple

On May 13, 2011, at 9:21 AM, David Avendasora wrote:

Hi all,

I've been doing a lot of work with EOQualifiers in the past few months,

Congratulations, that must feel very satisfying!

and while the new ERXKey-based, chainable qualifiers are a huge leap ahead of the standard EOQualifiers in terms of readability and clarity, they have always seemed just short of ideal. I believe I've come up with an improvement, but I want to get everyone's opinion first. Yes, even yours, Anjo. I'm ready. ;-)

Be careful of what you wish for.

First, let me give you a basic use case.

I have two Entities:
1) School
2) Student

Their relationship to each other is: School <->> Student (Shhh! it's just an example. Let's not complicate things.)

Now, let's say for a given school, I want all the active, red-headed students. Here's the way I originally learned (shudder):

EOQualifier qual1 = EOQualifier.qualifierWithQualifierFormat("hairColor=%@", new NSArray("Red"));
EOQualifier qual2 = new EOKeyValueQualifier("isActive", EOQualifier.QualifierOperatorEqual, true);
NSArray studentQualifier = new NSMutableArray();
studentQualifier.add(qual1);
studentQualifier.add(qual2);
EOQualifier studentQualifiers = new EOAndQualifier(studentQualifier);

EOQualifier studentQualifiers = new EOAndQualifier(new NSMutableArray(new EOQualifier[]{qual1, qual2});

NSArray redheadedStudents = mySchool().students(studentQualifiers);

Horribly unreadable,

Read: "it makes my lips hurt!"

with lots of grunt-work to get things setup before you can even use the qualifier for anything! That and incredibly unsafe due to the use of "Magic Strings" that will break, but only at runtime when you change anything in the model (sure, there's ways around that, but they usually make the code even less readable).

Then along came ERXKey chainable qualifiers and you could do it all with one (reasonable) line of code:

NSArray<Student> redheadedStudents = mySchool.students(Student.IS_ACTIVE.isTrue().and(Student.HAIR_COLOR.eq("Red")));

Which is pretty darn readable. Hugely better than the original way. HUGELY. But yet... you still need to spend a bit of time interpreting it when you first come across it.

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

"But where did the 'that(EOQualifier)' come from?" you ask?

That's (no pun intended) the key (oh, wow. I'm on a roll!) to the improvement.

I have added the following simple method to my EOGenericRecord subclass:

public static ERXAndQualifier that(EOQualifier qualifier) {
return new ERXAndQualifier(new NSArray<EOQualifier>(qualifier));
}

Basically, all this method does is coerce a standard EOQualifier into a chainable one (IERXChainableQualifier) and uses a conjunction to better tie the qualifier(s) to the Entity that they are qualifying. My #1 goal was to make places where I use qualifiers as sentence-like as possible, and I think Student.that(haveRedHair).and(areActive) is very readable.

So, what do you all think? Is there some flaw inherent in the system? Am I missing something? Would it be worth putting into ERXGenericRecord?

I am all for more readable, so I have no objection to this being in Wonder. Though Ramsey also had a good point about English syntax sometimes being less than optimal.

Now what would be REALLY cool is if you could get the templates to pre-generate qualifiers like:

EOQualifier haveRedHair = Student.HAIR_COLOR.eq(MyAppConstants.RED_HAIR);
EOQualifier areActive = Student.IS_ACTIVE.isTrue();

Chuck

References:
	>More Readable EOQualifiers (From: David Avendasora <email@hidden>)