Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #31104
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: "null", polymorphism and TCO |
| Date | 2015-02-10 10:37 +0100 |
| Organization | MB-NET.NET for Open-News-Network e.V. |
| Message-ID | <mbcjh4$388$1@gwaiyur.mb-net.net> (permalink) |
| References | <null-20150208185452@ram.dialup.fu-berlin.de> <mcmurtrie-19F4EE.23064308022015@news.sonic.net> <mba2ip$3nr$1@gwaiyur.mb-net.net> <mcmurtrie-338D50.20354409022015@news.sonic.net> |
On 10.02.15 05.35, Kevin McMurtrie wrote:
> An enum named something like EOF is, of course, much better but it can't
> be put into BlockingDeque<String>.
Since Java uses type erasure I would not bet on it. With some cast to a
non-generic container you will probably succeed. But you will also
dislike the exception when extracting it as a String.
> Every once in a while I hear talk of adding automatic String interning
> or optimizing away the String(String) constructor such that this becomes
> true:
> new String("foo") == "foo"
>
> It would surely break tons of code. Not only would it break unique
> tokens, but it would break WeakHashMap<String, ?> too.
Probably no one will ever remove an explicit constructor call.
But this does not apply if you assign string constants. E.g.
String s1 = "foo";
s1 == "foo" // might be true
Probably it will be true in most cases since the Java compiler will
likely not create two instances of the same constant. But I am unsure
what happens if the two lines are in different java or jar files. I
think it is simply undefined behavior.
So in your example
static final String endOfQueue= new String();
should do the job as well.
This is similar to the old style typesafe enum pattern:
final class MyEnum
{ private final int Value;
private MyEnum(int value) { Value = value; }
public static final MyEnum AVALUE = new MyEnum(1);
public static final MyEnum ANOTHERVALUE = new MyEnum(2);
...
}
This commonly used pattern is stupid. The integer is entirely superfluous.
final class MyEnum
{ private MyEnum() {}
public static final MyEnum AVALUE = new MyEnum();
public static final MyEnum ANOTHERVALUE = new MyEnum();
...
}
This will do the job as well.
Of course, the new type safe enums in Java are more convenient.
Marcel
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: "null", polymorphism and TCO Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-02-08 23:06 -0800
Re: "null", polymorphism and TCO Marcel Mueller <news.5.maazl@spamgourmet.org> - 2015-02-09 11:36 +0100
Re: "null", polymorphism and TCO Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-02-09 20:35 -0800
Re: "null", polymorphism and TCO Marcel Mueller <news.5.maazl@spamgourmet.org> - 2015-02-10 10:37 +0100
Re: "null", polymorphism and TCO Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-02-10 12:51 -0600
csiph-web