Eliminate, alter, or make caveats to references to type-safety.

[Revolucent]

Strictly speaking, CDQI's filtering is not type safe. Using a proxy, we can make a comparison to any type, e.g.,

let department = DepartmentAttribute()
let predicate: NSPredicate = department.name == 7

This produces the predicate "name == 7", which will probably fail at runtime. I have no plans to create a truly type-safe version of CDQI. CDQI is focused around flexibly building keypaths and predicates, not type-safety per se.

[patgoley]

Hey Gregory, really like what you've done with this framework and I think I can help you solve at least part of the type safety issue. Take a look at the branch on my fork called typesafe-attributes (specifically this file. Created a protocol called TypedExpressionConvertible that extends CustomExpressionConvertable to provide an associated type (the value type of the attribute). Then I've constrained the custom == operator for attributes to the value type of the attribute (see here).

If you check out the branch and look at FilterTests, find the use of the new custom operator (not using == for now to avoid a large refactor for the example). You'll find that $0.department.name ** "Engineering" compiles while $0.department.name ** 7 does not.

Furthermore, I've updated cdqi to pull the attribute type from the model file and use it to template the Attribute files (needs some sanitization).

If you're good with this approach, I basically just need to implement TypedExpressionConvertible for each data type available in Core Data, and it's stupidly simple to do so.

[invoy-ghigley]

Pat,

Thanks for the kind words! I haven't had a chance to look at the typesafe-attributes branch yet, but the idea sounds great. I'll take a look at the code when I have some free time in the next few days. (Most likely it will be this evening EST, though.)

In early prototypes of CDQI—before I ever had it on Github—I had something similar, but ultimately I removed it because of the great many numeric types Swift has. Implementing type safety for Int, UInt, Int32, Float, CGFloat, Double, etc. got to be a bit crazy. My biggest concern with this is that it should be able to take just about any numeric type we can throw at it absolutely seemlessly, whether expressed as a literal (i.e., 7) or a variable (i.e., let x: Double = 7; foo.bar == x).

If you can pull it off, I'm strongly in favor of adding it.

Greg

[patgoley]

Good point about the numeric types, I'll try to come up with something to handle that. The other odd case is a transformable attribute. Maybe the easiest solution is to let them just be KeyAttributes and be comparable to Any. Another options is that TransformableAttribute is a generic type, where T is the type being transformed in and out of the store (could be specified in the user info of the attribute for example). I'll work on a few things and submit a pull request in the near future.

[Revolucent]

Closed in favor of #26.