Re: Java compatibility issues (WAS: MF having issues?)

[post slightly re-ordered]

"Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx> wrote in message news:47972lFeicknU1@xxxxxxxxxxxxxxxxx
Richard<riplin@xxxxxxxxxxxx> 03/07/06 2:11 PM >>>
am not even sure that anyone wants evaluate to be included in Java or
any other language, it has its own idiom.

Without something similar to COBOL's EVALUATE you must, in Java, do
something like....

if (myString == "one") {
one();
}
else if (myString == "two") {
two();
}
else if (myString == "three") {
three();
}
else {
four();
}

Of course the above assumes we're comparing the value of the object myString
and not the object itself. I'm now totally confused as to which does
what...

As Richard said, == compares references ("pointer addresses" if you want to think of that way, though in a technical/pedantic manner, that's not strictly correct), while .equals() invokes the "equals" method, which can be programmed to do anything you want. In the case of Strings, "equals" compares the contents of the strings for equality (in a case-sensitive manner).

So in Java, you'd probably be writing:

if ("one".equals(myString)) {
one();
} else if ("two".equals(myString)) {
two();
}
/*etc.*/



Wouldn't it be nicer to say:
switch (myString) {
case "one":
one();
break;
case "two":
two();
break;
case "three":
three();
break;
default:
four();
break;
}

In the special case of Java, I'd say "yes". The reason is that Java already made the mistake (well, it's a mistake in my opinion) of sometimes treating Strings like primitives, and other times treating them like Objects. The above kind of construct perpetuates this illusion that Strings are like primitives.

So "normally", I'd say "no", and that the above construct would detract from the (mathematical) elegance of the language. However, since Java has already went down the road of treating Strings like primitive, the above construct won't add much more harm, and does provide some convenience to the programmer, so my final answer is "Yes, that'd be nice."


(Actually, eliminating those silly 'breaks' woul be even nicer, but...)

I agree. I'd like for the default behaviour to be a break, and if a fall-through is desired, for that to be explicitly said. E.g.

switch (myInteger) {
case 1:
handleOne();
case 2:
fallthrough;
case 3:
fallthrough;
case 4:
handleTwoToFourButNotFive();
fallthrough;
case 5:
handleTwoToFive();
default:
handleDefaultCase();
}

- Oliver

.

Relevant Pages

  • Re: add support for other languages
    ... language DLLs or a single DLL with multiple language support, ... Just compile in Unicode ... You can create a hand-edited resource that contains Unicode strings, but you have to do it ... I don't know where is the language support comes into ...
    (microsoft.public.vc.mfc)
  • Re: Two Questions about "strlen", "strcat" and "strcpy"
    ... >>Important is that we have in the standard language a way of using ... > No. zero terminated strings is the whole problem in the first place. ... > programmer to think in terms of implementation and constantly respin ... The standards comitee refuses any change, ...
    (comp.lang.c)
  • Re: GNU gettext
    ... The gettext documentation explains how the keys work. ... translation files, or that you'd need to write a small utility to help ... gettext was desined for plain C, the keys are C strings ... as a developer you have no clue what every language ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How come Ada isnt more popular?
    ... A language with a Hinldey-Milner type system ... fixed size strings, unbounded strings, suffix tree. ... container varies, the element does not. ...
    (comp.lang.ada)
  • Re: Substituting the main menu bar(s)
    ... I have tab-separated-value table of strings maintained with Excel, with a column for each language. ... All it does is replace the strings according to the translation table. ... I also have a batch file which calls the translation app, and then invokes the compiler on each resource-only DLL project. ...
    (microsoft.public.vc.mfc)