On Thu, Oct 7, 2010 at 3:16 PM, Stanislav Muhametsin <[email protected]> wrote:
>> Can you elaborate on why this is the case now? > > Hmm, actually the > > public static <T> EqualsPredicate<String> eq( final Association<T> property, > final T value ) > > was not done by me (IIRC), since it already was there when I started > resolving QI-214. So naturally the result of another 'eq' was to be put in > same way. They both create equals-predicate on target's Identity property, > and since it is of type String, the predicate is EqualsPredicate<String>. So, it is really that the underlying implementation of identity equality that is "leaking" through to the API level?? Rickard, what do you think of this? I think the issue is that equality is defined by identity, which we have nailed to String long time ago, and that String bubble up to the Query API. The Association doesn't hold Identity either, it is an EntityReference, internally, so this String approach makes a lot more sense from an implementation point of view, albeit a little bit 'ugly' at the API. May I suggest that for 1.3, we spend time to revise the Query API and have a more involving discussion on what works and what needs to be improved?? Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
