[cmake-developers] if (FOO == BAR) ...

[David Cole]

Are you proposing that == behaves as STREQUAL, or as EQUAL?

 

Similarly, would you propose < and > for numbers only, or for string comparisons?

 

You’ll just add to the mix of possibilities, and add to people’s confusion by adding these. At least the existing stuff is clearly string OR numeric comparisons, even though people are thwarted in their attempts at full understanding by the strangeness of the “if(VARIABLE” rules. 

 

I don’t think these are a good idea, unless there is a very clear benefit to adding them.

 

You cite these advantages:

 

- it implements the behaviour probably most people expect

Are you sure? I am unclear about whether == means EQUAL or STREQUAL, so I don’t really know what to expect from it... And given that I already know how these things work with if(VARIABLE constructs, I would expect that same thing from this new syntax. i.e. if(VAR == 5) works just like if(${VAR} == 5)


- it shouldn't be able to break anything

“Shouldn’t” is not the same as “definitely will not” -- I agree it’s unlikely to break anything, but unlikely breakages have been known to occur


- the syntax is nice

Agreed.


- it doesn't need a policy, existing behaviour doesn't change

Agreed. (Unless you still expect the if(VAR behavior as you have with the other operators.)


- minimal implementation effort, i.e. we could have it right now

So what? That’s an advantage for you developing the code. What we seek is an advantage for people writing IF commands, to understand the CMake IF constructs fully without adding too much to their cognitive load. Putting yet another set of operators into the mix doesn’t decrease the level of understanding necessary to use it correctly.

 

I’m against this proposal unless you can change my mind.

 

 

😊

David C.

 

(Thought you were done with me, did ya?)


 

 

From: Alexander Neundorf
Sent: ‎March‎ ‎20‎, ‎2013 ‎4‎:‎12‎ ‎PM
To: cmake-developers at cmake.org
Subject: Re: [cmake-developers] if (FOO == BAR) ...


On Thursday 14 March 2013, Brad King wrote:
> On 03/14/2013 03:47 PM, Alexander Neundorf wrote:
> > I pushed the AddEqualOperator to stage, it adds the == operator to if(),
> > which simply string-compares the both arguments, with no variable lookup
> > (... which can lead to unwanted effects when using STREQUAL)
> > 
> > Does that look like a good solution ?
> 
> It adds yet another interface to the if() command.  Syntactically
> the name "==" tells me nothing about how the comparison is done,
> and we don't have typed values.  Once "==" is there people will
> want <,<=,>,>=,etc. and they will all have the same ambiguity as
> to how values like "0" v. "0.0" are handled.

Yes, I am aware of all that, I was thinking even about adding <, >, etc.

I know that adding == is not the ideal solution, I'd also a prefer if STREQUAL 
wouldn't have the issue it has.

Still simply adding == has its advantages:
- it implements the behaviour probably most people expect
- it shouldn't be able to break anything
- the syntax is nice
- it doesn't need a policy, existing behaviour doesn't change
- minimal implementation effort, i.e. we could have it right now

Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130320/4f7fbdc2/attachment.html>