Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #31104

Re: "null", polymorphism and TCO

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>

Show all headers | View raw


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


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