Jump to content
  • Advertisement
Sign in to follow this  
DevineCaesar

Are primitive types necessary for Game Programming?

This topic is 2086 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites

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()...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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). Edited by cr88192

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!