Add .toString() to all Integer Getters

Just as the title says.

In My Opinion, this

player.getHealth().toString();

looks nicer than this

String.valueOf(player.getHealth());

Is it possible to monkey patch primitive data types in Java? Otherwise you’re probably out of luck.

1 Like

I mean it wouldn’t be that hard to just add the method…

String i = player.getHealth() + "";
2 Likes

Still takes an extra line.

You can’t just add that method to primitive classes, afaik. The only way around that I can think of is to create a utility class and have something like

String number = Util.toString(4.0);

As @J_Triggs said, concatenating it to an empty String is generally the shortest way. I don’t see how it’d need an extra line though. Example?

On a latent note, instead of trying to add a toString() method to a primitive double or float, maybe it’d be more sensible to request a player.getHealthAsString() method instead. I don’t see the use, honestly, but it’s the next best option that I can think of.

I guess I’ll just use that.

I don’t know Java, but a quick look at the docs revealed that Object has toString() and Integer, Double and Float are overriding these methods and return a string representation of the number.
So, shouldn’t it be possible to call player.getHealth().toString(); (assuming that getHealth returns an int)?

int (primitive) and Integer (object) are different.

3 Likes

toString() also may not always return what you expect. Often times, it just returns the memory address of the stored variable instead of a readable version of itself. In order to add a decent toString() for those numbers, you’d likely need to create a new class and store the value inside it, then override Object’s toString() and return the value how you’d like. Not worth it by any means.

You want to completely rewrite Java, just so you can write int.toString()?

You can save some time with concatenation, which happily absorbs a String next to a primitive. Or there’s always StringBuilder whose append methods take primitive types.

This is a remarkably strange request which is easily solved with the above stated solutions :slight_smile:

3 Likes

Very likely he wants this because the Logger needs a String.

Either use System.out.println(object);

or a helper method that takes an object and logs it as a String:

public static void log(Object o)
{
Bukkit.getLogger().log(Level.INFO, “{0}”, o);
}

Scala naturally fixes this wart too, but there is nothing Sponge can do about it in plain Java.

Well, why not just make the methods return a wrapped int (Integer). It can be used almost exactly like the
primitive int.

Integer integer = 42;
integer.toString();

Although I personally consider that a tremendous waste of resources, especially because string concat can just take primitives and using the int wrapped in an object just for the .toString() seems wasteful.

Wouldn’t that be easy fixed if they do something like this:

public Integer getInteger(){
   int number = 8;
   return number; //no need to cast as well
}

No need to make this harder than it is.

no need to cast as well

It’s called autoboxing, and what it actually does is:

public Integer getInteger()
{
    int number = 8;
    return Integer.valueOf(number);
}

Looking at the code of Integer.valueOf(int) (source):

public static Integer valueOf(int i) {
    final int offset = 128;
    if (i >= -128 && i <= 127) { // must cache
        return IntegerCache.cache[i + offset];
    }
    return new Integer(i);
}

This takes about ten times longer than just returning the primitive type and possibly even allocates a new object, which, for use in calculations, would have to be unboxed again, resulting in another loss of performance, all for that in case you wanted to convert it to a string, you’d have the convenience of not having to put

"" +

in front of a function call? Well, I vote against this.

7 Likes

@Siguza I wasn’t aware of the autoboxing thing, thanks for explaining this :smiley:.

+1 for Source included

Which is why we should’ve use C# which fixes bugs, I mean features, such as primitives not having a decent toString(), or Objects returning their memory location on toString()…