On Jul 31, 2006, at 7:52 AM, Robert Sanderson wrote:

>> I may have missed something, but what were the objections to:
>> eq ne gt lt ge le ?

They make sense to me

> Currently, the impact on existing queries is minimal as = can  
> always be
> mapped to the exact equality for strings, or adj for words.
> But by changing all of the relations, it has a much higher impact on
> existing queries.
>
>
> On thinking about = vs ==, is it really a problem?  The bug which
> catches people out in programming is typically:
> 	if (a = b) { ... }   // attempting if a is b
> not:
> 	a == a + 1           // attempting increment a by 1
>
> So to translate:
> 	identifier = "abc 123"
> when you mean:
> 	identifier == "abc 123"
>
> But any sane server will map that = to == anyway, thereby doing  
> what you
> meant regardless.
>
> I can't see anyone giving the query:
> 	word == fish
> When they actually meant:
> 	word = fish
> In the same way that no one writes equality when they mean assignment.
>
>
> I'm going to flipflop and prefer '==' to 'eq' now, because I don't  
> think
> that the disadvantage of == is real :)
>
> Rob

IMHO, The problem I see is one of "programming language" syntax vs  
"query language" syntax. "==" as a relationa operator is a  
programming language construct.  "=" as a relational operator is a  
query language construct. If the query language can capture 80 of the  
cases with the "basic" relational operations, uniary flags and  
boolean operators used is query languages today, why dirty it up with  
more complexity, If folks are going to adopt the technology, the  
learning curve and simplicity are key to its success and popularity.


Mark R. Diggory
~~~~~~~~~~~~~
DSpace Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology