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@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--
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
