exact string compare

[FFF]

Karl,
Compatibility, compatibility.
We have to support the difference between '=' and '==' for the VO and Vulcan dialect.
And like i said before: the '=' operator is NOT supported for strings in the Core language because it depends on a runtime function (which again depends on the SetExact setting)

Robert

Robert,
if there ist no behavioural difference of = and ==, i wonder why the "special" case == exists at all ?

Now you puzzle me - Core has SetExact? If not, imho there's no need for millions of extra "=" to type, so i would drop the == in favour of "="...

[wriedmann]

Hi Robert,

Wolfgang,

I have added the !== operator earlier today. It does what you asked for.
And I discovered that the != operator for Strings was not doing the same that the Vulcan operator did, but now it does: it calls a runtime function for its wok.
And the <> operator and the # operator do the same as the != operator.

Robert

thank you very much for this addition! So my wish had also a side effect <g>

Wolfgang

[robert]

Wolfgang,

I am sorry to have to report this, but I have rolled back that change. Upon further checking I found that the "!=" operator already was doing the same as "!(<lhs> == <rhs>).
So there is really no need for a !== operator.

When checking this I found some other strange behaviour. Try the following code in VO and Vulcan:

Code: Select all

 
    FUNCTION Start
    LOCAL cString AS STRING // USUAL
    LOCAL cString2 AS STRING // USUAL
    cString   := "ABC"
    cString2  := "A"
    //                                      // S-S U-S S-U U-U
    ? "==",     cString == cString2         // .F. .F. .F. .F.
    ? "!(==)",     !(cString == cString2)   // .T. .T. .T. .T.
    ? "=",         cString = cString2       // .T. .T. .T. .T.
    ? "!(=)",     !(cString = cString2)     // .F. .F. .F. .F.
    ? "!=",     cString != cString2         // .T. .F. .F. .F.
    WAIT   
    RETURN NIL

How can

Code: Select all

cString = cString2

be true and

Code: Select all

cString != cString2

be true at the same time.... Is this Quantum Logic ?

And now change one or both of the strings to a USUAL. Then in all cases the result of the last line is FALSE (in VO and Vulcan)!
What a mess...

The table above is the table of the results for VO.

Try the same in Vulcan and you will see that when the first local is a STRING and the second local a USUAL then the result for the '=' will be FALSE ! In that case both '=' and '!=' return FALSE ! Quantum Logic again...

I have no idea how we can properly implement this. Should there be a difference between the VO and Vulcan dialect for the case when comparing string (LHS) and usual (RHS) ?

We will look further into this and will come with a solution, I am sure of that.
But how can such an important feature of a language be soo strangely implemented.

Robert

[wriedmann]

Hi Robert,

unfortunately you are right: this is a complete mess! And change a setting somewhere and a LOT of working code will not work correctly anymore.

This is why I use only "==" in VO, and when I compare strings to be different, I use

Code: Select all

"! cString1 == cString2"

all the time. Otherwise it depends if you write

Code: Select all

cString1 != cString2

or

Code: Select all

cString2 != cString1

This is completely illogical and a source for continuos errors.

But that things change if one or both strings are defined as usual is completely new to me, and will led to errors in a LOT of VO or Vulcan code if parameters are changed between strings and usual.

IMHO X# should behave as VO in the VO dialect, and as Vulcan in the Vulcan dialect, and correctly in the Core dialect.
But of course the differences between VO and Vulcan can cause errors in the migration process.

What I would propose: a clear documentation about how VO and Vulcan works.

For the "=" operator I would have a simple solution: introduce a compiler warning.

For the "!=" operator such a warning would be useful too when it comes to string compares, but this would be a nightmare when moving old code....

Therefore I had asked for the "!==" operator, something that behaves correctly also in the VO and Vulcan dialects - for the Core dialect in effect it is not needed as there the "!=" operator works as it should.

Wolfgang

[wriedmann]

Hi Robert,

an addition: I have used and expanded your test code a bit, and now I know why I had sometimes unexpected results with the != operator: in code like this

Code: Select all

oServer:FieldGet( #StringVar) != cString

the first variable is treated as usual, and therefore behaves differently than

Code: Select all

cStringVar := oServer:FieldGet( #StringVar )
cStringVar != cString

I'm working in VO for more than 20 years, and have never discovered this very important difference!

Wolfgang

[Frank Maraite]

In 2006 or so I discovered a bug in bBrowser with these issues.

Since then I always wrote, like Wolfgang, !(String1 == String2).

I did, what I always do in such a situation: I did a search and changed all occurences in the next half hour. Why: It took me for example 4 hours to identify the bug. So a half hour is relatively short.

This thread again shows how important well designed tests are.

Frank

[Chris]

Hi Wolfgang,

That extremely messy behavior of vulcan is actually exactly the same as in VO! Actually it is VO that is a complete mess on that regard, with different results based on if the arguments are STRINGs or strings inside USUALs. And if you have a look also at the >,>=,<,<= operators, their behavior is even more crazy!

What we did in vulcan, was to emulate that crazy VO behavior (see the documentation on the /vo13 option), in order to achieve 100% compatibility at runtime for vulcan applications ported from VO. So vulcan and VO work the same way in that regard (except for a couple minor cases when we missed something in vulcan), so I think both the VO/Vulcan dialects of x# should work the same way as VO, too. The Core dialect does not support USUALs, so it's all normal in it.

Chris

[wriedmann]

Hi Chris,

I agree with you that this behavior is "crazy" and "messy" - and it makes it important for me to be able to move all my several 100.000s of lines of VO code to X#.

So I look forward to the day when the X# runtime is ready and I can move over my applications!

Wolfgang

P.S. unfortunately currently I have no machine for my old XP disc with Clipper installed, but when this notebook returns, I'l make some tests also with Clipper - VO has inherited this strange behavoir from Clipper, I think.

[lumberjack]

I had a similar experience where I accidentally used = instead of == and had a huge problem in identifying why the VulcanRT assemblies were linked in, when I took care of making sure I don't use any VO specifics. Needless to say after communication with Chris I was finally able to quickly identify all the places using ILSpy and dump my assemblies in IL code and do a search for all Vulcan occurrences (thanks Chris!)

But in short I agree, the = behavior was always something that bite me, and I even in VO days wrote my own Compare if the = behavior was required, which is today encapsulated in the String.StartsWith() of .net

LJ

[Chris]

You're welcome LJ!

Chris