On Apr 12, 6:20 pm, "Joe Smith" <unknown_kev_...@hotmail.com> wrote: > I'm not fundemantally opposed to overriding the ! operator, as long as the > result is strictly a locigal negation of the original, although some people > may have a problem with it breaking the double negation to coerce to true > boolean. Since that is a hack anyway, I don't much care for the loss. > > I would however suggest that any documentation prefer the format used in the > second example, as a way of encouraging readability. When the first case is > used, an extra set of partentheses may help readability since somebody not > particular familar with ruby's operator precedence could potentially misread > it.
The result would definitely be a complement to the original, which seems to me in keeping with the concept of "not" to begin with. In fact, over the weekend I modified the patch to handle complements more cleanly. That is, each predicate has a complement method which is used behind the scenes. This prevents successive negations from causing the accumulation of "nots" and using unnecessary memory with Not predicates containing Not predicates containing... you get the idea. Repeated nots toggle between the original and negated meaning, much like multiple nots will do with boolean true/false: uby-head > articles[:title].eq('Hello').to_sql => "\"articles\".\"title\" = 'Hello'" ruby-head > (!articles[:title].eq('Hello')).to_sql => "\"articles\".\"title\" != 'Hello'" ruby-head > (!!articles[:title].eq('Hello')).to_sql => "\"articles\".\"title\" = 'Hello'" I think this cleans up the generated SQL considerably, though I'm not sure from a DB/query optimization standpoint which one might be more efficient. I'd think that depending on the DB engine, they should end up being optimized identically, anyway, but I've been down that road before and sometimes queries get optimized in strange ways. Consider negation of a matches_any query. After the complement changes: ruby-head > articles[:title].matches_any('Hello%', 'Hi%').to_sql => "(\"articles\".\"title\" LIKE 'Hello%' OR \"articles\".\"title\" LIKE 'Hi%')" ruby-head > (!articles[:title].matches_any('Hello%', 'Hi%')).to_sql => "(\"articles\".\"title\" NOT LIKE 'Hello%' AND \"articles\".\"title \" NOT LIKE 'Hi%')" Previously, it would have yielded: NOT(\"articles\".\"title\" LIKE 'Hello%' OR \"articles\".\"title\" LIKE 'Hi%') They're logically equivalent, but I'm not certain if some database engines would optimize one better than the other. -Ernie Miller http://metautonomo.us -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.