TOPIC:

Hello,

sometimes in VO I'm writing such code:

if ! cString1 == cString2

because

if cString1 != cString2

depends on SetExact(). Personally I would like an operator like "!==" to have an exact version of "!=" like "==" for "="

If there is already something similar, please ignore. And of course, it has absolutely no priority.

Wolfgang

Wolfgang,

In the core dialect afaik there is no difference between string = string and string == string.

Similarly string != string is the same as !(string == string).

We could add an operator !== and map it to the Core != operator for all dialects if you want.
That should not be too difficult.

Robert

We could add an operator !== and map it to the Core != operator for all dialects if you want.
That should not be too difficult.

That would be very welcome! I will have a LOT of code in Vulcan and VO dialects in the future. New code is always written in Core dialect. And so I don't have to think about the dialect when working in older code.

Wolfgang

Robert wrote: Wolfgang,

In the core dialect afaik there is no difference between string = string and string == string

Robert

pmfji, that means, in core you can't (easily) compare substring with fullstring?
Just had a go:
FUNCTION Start() AS VOID
LOCAL c1, c2 AS STRING
? "c1 = ", c1:= "a"
? "c2 = ", c2:="abc"

?"c1==c2: " ,c1==c2
? "c2==c1: ", c2==c1
?"c1=c2: " ,c1=c2
? "c2=c1: ", c2=c1
Return

the last two lines won't compile in core - "no such operator".

?
Karl

Hi Karl,

The partial string compare operator is not a compiler thing, it is implemented through a runtime function because its behavior depends on different things like the state of SetExact(), the type of the operands etc. The Core dialect has no runtime, so this operator is not supported.

Theoretically we could implement it at the compiler level in Core, but that would cause trouble like it would have different results than in the other dialects and also what would the "!=" operator mean then? Should it be the opposite of "=" or the opposite of "=="?. In VO the behavior of that operator is crazy, depending on the operands it some cases it means !(==) and in others !(=). It was obviously a big nightmare emulating the same behavior in vulcan for compatibility with VO.. The Core dialect is the "cleanest" x# dialect, so I think it's better leaving this feature out in this dialect.

Chris

Hi Chris,

In VO the behavior of that operator is crazy, depending on the operands it some cases it means !(==) and in others !(=).

I couldn't agree more!

Therefore in VO I'm always writing

if ! cString1 == cString2

and I'm very happy that at least in the Core dialect this problem is solved.

Wolfgang

Karl,

You are right. The single equals operator does not work in the Core dialect for strings. We only support the double equals.

To compare a substring you need to use the String.Compare() method and pass it the start position and length that you want to compare.

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

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

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

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

Robert wrote: 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

FFF wrote: 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 "="...

Hi Robert,

Robert wrote: 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

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:

How canbe true andbe 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

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 useall the time. Otherwise it depends if you write

or

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

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

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

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

Wolfgang

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

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

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.

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

You're welcome LJ!

Chris