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.

Reply via email to