Are primitive types necessary for Game Programming?

Started by
16 comments, last by TheChubu 11 years, 1 month ago

I was stumbling around the net and discovered that suggestions have been made for primitive types to be removed from future versions of the Java programming language. This got me thinking, even though Java more or less "does it for you" when it comes to memory management surely there is an inherent understanding that using primitives instead of objects where appropriate would be better? or is that a false assumption on my part?

For simple things like keeping track of a player's numerical attributes number of lives, health, experience, etc I would have thought using primitive types instead of Object types would have made more sense.

There are other programming languages that don't have primitive types at all, but to my knowledge they aren't as popular for games as C/C++ and Java etc wihich do have primitives. So the question is quite simply, are primitive types necessary for Game Programming? Would there be any knock on effects of removing them from a language?

Advertisement
I think you need to define your terms or at least provide a link to these discussions. In most cases "primitive types" mean that the types that are built into the language. If your language doesn't have any primitive types then you can't have any types because there are no types to define them in terms of. How can you have a score if your language doesn't support the idea of numbers? (OK the lambda calculus can give you an example, but there is still a basic primitive data structure used to define integral types.)

I think they must mean, and not sure because it's been a while since I touched Java, but getting rid of the versions of primitive types that don't behave like objects, Like in Java, isn't there int and Integer? and of those only Integer would let you do introspection and could be inserted into the old-style Java containers in which the data values had to inherit from Object and so forth. With Integer in theory you could do some like 2.ToString()...

To clarify, in terms of Java this will mean direct access to primitive types for the purpose of declaring variables will be removed. Without direct access to these types every variable you declare will be an Object. So int for example will no longer be available instead you will have to use the Integer class and create an Object. The language will still have an internal concept of numbers and the ability to manipulate them obviously but in terms of writing code everything will have to be an Object.

Source: The Register: Java won't curl up and die like Cobol, insists Oracle

For the Java Development Kit (JDK) 10 or after, a fundamental change is being discussed: making the Java language Object Oriented. This might see the introduction of a unified type system that turns everything into objects and means no more primitives. The JDK is the developer kit that
is officially released by Oracle, based on the work of the Oracle- and IBM-led OpenJDK project


For example:


public static void main(String[] args)
{
     int appleCount = 10;

     System.out.println("You have " + appleCount + " apples");
}

This will no longer be possible, instead you will have to use Objects:


public static void main(String[] args)
{
     Integer appleCount = new Integer(10);

     System.out.println("You have " + appleCount.toString() + " apples");
}

I know this example is unrealistic it's just meant to illustrate the point.

I think they must mean, and not sure because it's been a while since I touched Java, but getting rid of the versions of primitive types that don't behave like objects, Like in Java, isn't there int and Integer? and of those only Integer would let you do introspection and could be inserted into the old-style Java containers in which the data values had to inherit from Object and so forth. With Integer in theory you could do some like 2.ToString()...

IIRC, this is basically part of it.
the idea would basically putting a layer of gloss over int vs Integer, making it look more like 'int' was simply an instance of Integer, ...

practically though, you can't really (actually) get rid of primitive types and have any semblance of performance.

I could be wrong though, given I am not really a Java developer...

I haven't used much Java either, but in C# for example string (lowercase) is an alias for the System.String class, so it's probably the same with your Java example. But as it's also a keyword, in this context it is treated like a primitive type. Conventionally, you use the uppercase String when using its methods and operations.

New game in progress: Project SeedWorld

My development blog: Electronic Meteor

I haven't used much Java either, but in C# for example string (lowercase) is an alias for the System.String class, so it's probably the same with your Java example. But as it's also a keyword, in this context it is treated like a primitive type. Conventionally, you use the uppercase String when using its methods and operations.

pretty much:
int -> System.Int32
string -> System.String
...

it also allows fairly easily converting between int and object.

int i;
object o;
o=(object)i;
i=(int)o;


it is also very unlikely that Oracle would make a language change which would break pretty much all existing code.


FWIW: my scripting language also does some similar type aliasing, but actually more so, as it is 3 way: variant <-> primitive <-> class.

for example, there is a primitive type (int), a class (Integer), and a variant (fixnum).
so, for example:
var v=3; //type is variant (fixnum)
int i=v; //type is primitive (int)
s=v.toString(); //may quietly send it off to the class (*1)
s=i.toString(); //likewise (*1)

*1: partly pretend here, as implemented, ".toString()" is actually an intrinsic operator in this case, but for some other types it may actually call the "toString()" method...

side note: a fixnum is basically a tagged reference (similar to a pointer), where a few tag bits may indicate whether the reference points to an object, or holds a value such as an integer or floating-point number. this is partly because creating object instances just to convert a primitive to a reference would be unreasonably expensive, and it is much cheaper simply to shove the integer into the reference (in the JIT, for example, converting an 'int' to a 'fixnum' is essentially 2 CPU instructions, namely CDQ+XOR, or would be MOVSX+XOR for x86-64).

however, I make no claim that the language "gets rid of" primitive types, rather than the line between primitive/variant/instance being sometimes slightly fuzzy...

actually, 'string' is another example: in my case it is actually an intrinsic type (as variant) as well, but converts to a 'String' class in the off-chance this is needed. this is partly because there are much cheaper ways to store strings than as object instances (IOW: M-UTF-8 globs of bytes off in a string table somewhere). synthesis-on-demand seemed to be a generally cheaper option than having every in-language string pay the overhead of both a heap-allocated object instance and also a heap-allocated character-array.

...


Java is essentially approaching things from the opposite direction, IIRC with the more recent JVM versions internally adding a fixnum type mostly to fake the presence of an Integer instance, ... (mostly in their effort to make JRuby and Jython perform better).

I guess my main gripe with the idea of "Objects Everywhere" is that it will add complexity where it isn't needed.

If I have a player class with an int and an accessor method to get that int I would simply return that int and the value could be used.

With Objects everywhere since objects are passed by reference it wouldn't be possible to pass by value anymore - all primitives in java were passed by value - so now if you want to make sure the caller can't modify your member you'll have to create a copy and pass back the copy instead.

Same goes for calling methods, there'll be a lot more instances where the member will now have to be copied so that it can be passed to a method without worry that it might change the original.

I was stumbling around the net and discovered that suggestions have been made for primitive types to be removed from future versions of the Java programming language.

This is insanity in the Java community.

.Net (C#) has a best-of-both-worlds solution called "boxing".

If they made a change to Java they should implement a similar feature.

Removing primatives would wreck performance. You would have to allocate from the free-store for every field.

It would no longer be possible to create an actual array. You'd always get an array of handles.

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

I would wager that the argument is that the compiler is sufficiently intelligent to ellide such types' object-ness where possible, or otherwise reduce its space and performance overhead. Certain kinds of features (which Java may or may not have, I'm not familiar) like exporting a type through a library or DLL, JITting, might dissallow or defer the decision, but such is unavoidable. The primitive types naturally side-step such issues by declaring their intent. One approach might be declare an Integer in a special way that restricts the interface -- it might have some benefit to homogeneity of code, but its mostly just turning the problem on its head.

In general, though, if you can achieve similar performance and space utilization, whilst eliminating decisions (or regularizing them), then its best to let the compiler do what it thinks is right.

throw table_exception("(? ???)? ? ???");

This topic is closed to new replies.

Advertisement