Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (527)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (594)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3 4
  ignore  |  Print  
  What would you like to see in Java?  (Read 7666 times)
0 Members and 1 Guest are viewing this topic.
Offline actual

JGO Coder


Medals: 24



« Reply #30 - Posted 2013-10-08 01:29:25 »

One thing I would like is the ability to better fine tune the visibility of classes and methods. Often times I will want a class to be accessible by another class in a different package (maybe a sub package) but not publicly accessible.
Offline Jeremy
« Reply #31 - Posted 2013-10-08 01:41:16 »

One thing I would like is the ability to better fine tune the visibility of classes and methods. Often times I will want a class to be accessible by another class in a different package (maybe a sub package) but not publicly accessible.

C++ has this with friend classes. A feature I never use.

That said, the closest thing to a 'friend' class in Java is an inner class (which I use a lot)

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline SHC
« Reply #32 - Posted 2013-10-08 01:42:37 »

I don't know much but is friend classes something like partial classes of C#?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeremy
« Reply #33 - Posted 2013-10-08 01:47:23 »

I don't know much but is friend classes something like partial classes of C#?

Well, partial classes in C# compile into one class from various other partial classes but they alone aren't different classes. Friend classes are different classes but 'friends' have access to private members of their friends.

Partial Classes in C# are used a lot for partial code generation. I.e, to isolate generated code in a class from written code. For example, .Net has a form editor that edits a partial class of the form. Then the user programs into the other part for event handlers etc.

It's a cool feature, and it would be nice if Java supported it. Especially because any Form editors in Java demolish any sense of maintainability to the code.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline SHC
« Reply #34 - Posted 2013-10-08 01:54:15 »

Thanks for that clarification. Can you also give some examples where friend classes can be useful? I don't think they are used often.

Offline Jeremy
« Reply #35 - Posted 2013-10-08 02:01:54 »

Thanks for that clarification. Can you also give some examples where friend classes can be useful? I don't think they are used often.

I've honestly don't use them that much. But they can be compared pretty well to Java Inner Classes; and now that I think of it, where ever I've used an inner class in Java I would probably translate that in C++ to a friend relationship with my parent class.

An example for where you'd use a friendship in C++ is when you wanted a private inner class. You could protect your inner class's constructor and accesses with a friend relationship to it to instantiate it.

I'm not entirely sure if the logistics of that example are correct though, as I rarely ever use inner classes in C++.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline davidc

Senior Devvie


Medals: 5
Projects: 2



« Reply #36 - Posted 2013-10-08 09:25:01 »

I would like to see Java follow .Net in discarding checked exceptions. Allow them still be included as part of a method declaration, but not force them to be caught or declared. Far too often often novice programmers will take them option of catching and suppressing them, when that is quite often inappropriate. Java already has a mechanism in place for handling uncaught non-checked exceptions which should be used more often.
Offline Roquen
« Reply #37 - Posted 2013-10-08 13:00:14 »

Both paradigms were realized in the 50's. Neither were fully implemented until the 60's (LISP was considered a multi-paradigm language). To say functional programming was around a lot longer isn't quite accurate.
We're taking different perspectives.  LISP is meta, but it's the first language that truly allowed writing in a functional style...at least in my option.  Although bits-and-pieces of OO do indeed date to the 50s, SmallTalk is the first real OO language...and that's much later...call it 1980, but only on a very limited scale.  I suppose one could argue Simula, but (again IMHO) it was an important step along the way but not there yet.
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #38 - Posted 2013-10-08 13:57:47 »

Java explicitly went out of its way not to support Operator Overloading because of what it did to code in C++.

It didn't do anything to C++.

Bad programmers created operator overloading messes, not the language. It's a shame such useful functionality for responsible programmers has to be excluded because they were afraid of people abusing it. Which is stupid logic, because there will always be ways to abuse a languages features and make it look dumb.

1  
System.exit(1);


A fine example of code that should never be allowed.... bah! An application should have a proper shutdown protocol so all resources are properly disposed, bah! /sarcasm


Anyway, here are things that Java won't have with the newest version (which adds lots of things I've been drooling over) that I've been wanting:

1. structs - by this I mean a fixed-size object in memory that can easily be written and read from streams. something that doesn't get instantiated, it gets passed around by value. (ignore the fact that c++ classes are the exact same as structs, I'm using the term struct because many don't realize in C++ they're basically the same thing).
2. passing primitives and structs by reference (optionally of course) - with parameters AND returned variables
3. operator overloading - all overloadable operators that c++ currently provides
4. manual memory management - two new operators called alloc and delete which creates objects on the heap outside of the JVM. these objects have to be structs (or just fixed-size) and have to have a destructor
5. pointers
6. templating - java generics are nice in many instances, but templating offers things generics can't even come close to.
7. methods that return more than one thing

Now that I think about it.... I pretty much want C++ but with Java syntax and cross-platformness.






Offline xsvenson
« Reply #39 - Posted 2013-10-08 14:31:38 »

...

Bad programmers created operator overloading messes, not the language. It's a shame such useful functionality for responsible programmers has to be excluded because they were afraid of people abusing it. Which is stupid logic, because there will always be ways to abuse a languages features and make it look dumb.

...

This is kinda the same kind of argument that "Guns don't kill people, people do" (strawman, I know). In the end, it doesn't matter, because we are left to clean up the mess.

This is the reason, I don't want operator overloading: in the end, some of the code ends up in my workspace sooner or later and I will have to deal with it or clean up the mess or whatever comes.

What I would like to see, however, is modular JRE, which hopefully is coming.
And function pointers or method references.
Other than that, java is fine for me, not looking for a replacement nor has any other jvm language (that I have taken the liberty too look at) impressed me enough to try em out.
Edit: On some occasions I've missed multiple inheritance too.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #40 - Posted 2013-10-08 14:32:28 »

Again, I'm too lazy to yet again state how horrid is it not to have operator overloading.  The brush strokes are: "People can write bad code".  That happens the moment a language has the complexity of a macro assember...so you've already failed to nanny them.  "I don't want to look at badly written operators".  Then don't...why would you want to look a badly written code anyway.  "But it's at work".  Somebody's not doing their job then...hopefully it isn't you.

The bottom line is that, yeah operator overloading can be used to make horrid things.  The flip side is that without operator overloading any mathematical type which isn't natively supported by the language will be insured to be horrid.  Do the math.  Oh yeah and limited operators?  Once you get past reals and integers...that tiny set of operator symbols make the feature bordering on useless.  Besides most of the "issues" with bad operators in C++ would be a non-issue in java.  An IDE would decorate differently and you're just a click away from implementation.

Oh and:  ACCESSORS.  If the VM supported accessors where would be much happiness...the rest is just sugar.

Structures is a real biggy for a long list of reasons...to lazy to repeat.
Templates...you really want macros (no not preprocessing macros).  To be practical would need a new transport IR...which would be awesome for a long list of reasons...again too lazy to repeat.
manual memory management:  you don't need it if you have structures and arrays of structures.
methods that return more an one thing: structures again.
pointers:  Your point (yuck yuck) isn't clear...why?
Offline Sethir

Senior Newbie


Exp: 3 years



« Reply #41 - Posted 2013-10-08 14:39:04 »

I'm a bit pampered by PHP but I'd like to name my array keys. One other thing is Java2D. It's fine the way it is, but sometime I'd like to style it with CSS. It would be so much easier than calculating each and every coordinate.
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #42 - Posted 2013-10-08 14:41:42 »

Templates...you really want macros (no not preprocessing macros).  To be practical would need a new transport IR...which would be awesome for a long list of reasons...again too lazy to repeat.

You're right, I want macro'd classes/methods.

manual memory management:  you don't need it if you have structures and arrays of structures.

This is true, I wanted memory management because there can be such a large volume of objects the JVM has to check for garbage collection that it shouldn't have to because I know exactly when I want it deallocated.

methods that return more an one thing: structures again.

Yeah, didn't realize the overlap.

pointers:  Your point (yuck yuck) isn't clear...why?

Hmm at first it's because I wanted a chunk of data and have the ability to cast any point in that memory to any data type... then I realized you can do this with ByteBuffers (which are nicely "compiled" down into very efficient code) and having structs would also make pointers useless.

I also want some things added to the language that would make some nice syntactic sugar... like a nice clean way to instantiate and populate maps... and instantiating objects while setting they values. Meh.

Offline Roquen
« Reply #43 - Posted 2013-10-08 14:48:04 »

methods that return more an one thing: structures again.
Yeah, didn't realize the overlap.
Say you have a function that returns a pair-of-integers.  That's effectively a structure in the caller's frame.
Online Mac70
« Reply #44 - Posted 2013-10-08 16:44:09 »

Not language feature, but this would be very useful in IDE like Eclipse or NetBeans: ability to visually "merge" superclass fields and methods in class you currently edit.

Check out my Devblog! Smiley
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #45 - Posted 2013-10-08 19:05:03 »

Oh yeah, I forgot unions.

That would make color implementations sexy.

Offline Roquen
« Reply #46 - Posted 2013-10-08 19:12:11 »

You don't need unions...you need SIMD, which allows for a subset of unions and is then acceptable.  Which again means structures.
Offline Jeremy
« Reply #47 - Posted 2013-10-08 19:16:18 »

Java explicitly went out of its way not to support Operator Overloading because of what it did to code in C++.

It didn't do anything to C++.

Bad programmers created operator overloading messes, not the language. It's a shame such useful functionality for responsible programmers has to be excluded because they were afraid of people abusing it. Which is stupid logic, because there will always be ways to abuse a languages features and make it look dumb.

1  
System.exit(1);

A fine example of code that should never be allowed.... bah! An application should have a proper shutdown protocol so all resources are properly disposed, bah! /sarcasm


Anyway, here are things that Java won't have with the newest version (which adds lots of things I've been drooling over) that I've been wanting:

1. structs - by this I mean a fixed-size object in memory that can easily be written and read from streams. something that doesn't get instantiated, it gets passed around by value. (ignore the fact that c++ classes are the exact same as structs, I'm using the term struct because many don't realize in C++ they're basically the same thing).
2. passing primitives and structs by reference (optionally of course) - with parameters AND returned variables
3. operator overloading - all overloadable operators that c++ currently provides
4. manual memory management - two new operators called alloc and delete which creates objects on the heap outside of the JVM. these objects have to be structs (or just fixed-size) and have to have a destructor
5. pointers
6. templating - java generics are nice in many instances, but templating offers things generics can't even come close to.
7. methods that return more than one thing

Now that I think about it.... I pretty much want C++ but with Java syntax and cross-platformness.

From James Gosling (the father of Java)
"I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++....Then there's a community of about 10 percent that have actually used operator overloading appropriately and who really care about it, and for whom it's actually really important; this is almost exclusively people who do numerical work, where the notation is very important to appealing to people's intuition, because they come into it with an intuition about what the + means, and the ability to say "a + b" where a and b are complex numbers or matrices or something really does make sense."

A lot was done on C++'s account, and Java appealed primarily to C++ users when it arrived.

There is no reason you can't replace << with write, >> with read, + with add, - with subtract * with dot (or cross?)

It's just ascii art. You aren't an ascii artist, you're a programmer. There is no reason in hell for us to be throwing ascii art into our code.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline Troncoso

JGO Coder


Medals: 20



« Reply #48 - Posted 2013-10-08 19:26:09 »

Do people actually like "<<" and ">>" in C++? I thought that was the dumbest thing. C was doing just fine with printf/scanf and the variants.
Offline Roquen
« Reply #49 - Posted 2013-10-08 19:32:13 »

That's the thing about languages like C++ and Perl:  How hard can language design be?  Let's toss together features from various places and keep the "familiar" syntax...what could go wrong?  Everybody uses redirection in shell scripts...so that's how it should look in my grab-bag language to communicate with a stream.  I'm so awesome!
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #50 - Posted 2013-10-08 19:37:59 »

Do people actually like "<<" and ">>" in C++? I thought that was the dumbest thing. C was doing just fine with printf/scanf and the variants.

No, it wasn't. printf and the like are fundamentally type-unsafe and not extendable. You can scribble all over memory by accidentally mis-matching your format code and the actual type you pass it. And you're limited to the built-in type formatting that the functions support.

C++ streams and the insertion (<<) operator is *always* type safe, and you can override the insertion operator per-type to provide custom formatters (much like Java does with toString(), but more generically). The only disadvantage is the different syntax, and once you've used it for a while both become equally natural.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Troncoso

JGO Coder


Medals: 20



« Reply #51 - Posted 2013-10-08 19:41:54 »

I'm literally only talking about the syntax, mate. I'm saying C was fine without special IO operators. C++ could have just as easily accomplished what "<<" and ">>" do with simple function names.
Offline Roquen
« Reply #52 - Posted 2013-10-08 19:42:59 »

Err..ninja'd.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #53 - Posted 2013-10-08 19:45:19 »

C++ could have just as easily accomplished what "<<" and ">>" do with simple function names.

Not without either horrible resulting syntax, or a reduction in functionality.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Troncoso

JGO Coder


Medals: 20



« Reply #54 - Posted 2013-10-08 20:00:52 »

The syntax would just be a function name? How that looks horrible to you, I don't know.

cout(string);
coutf(string, ...);

Then again, I would just name them print/printf. Either way. That's just as clean as any method.
And what can those operators do that you can't do in a function?

Either way. It's preference. I'd prefer a function. You'd prefer the operators. This thread is about what we would like. (Though, in Java, but that's beside the point).
Offline Roquen
« Reply #55 - Posted 2013-10-08 20:06:02 »

ostream.put(foo).put(bar).eof();

But this really isn't what operator overloading is about anyway.
Offline kingroka123

JGO Ninja


Medals: 41
Projects: 6
Exp: 1 year


Gamer's Helmet


« Reply #56 - Posted 2013-10-08 20:44:42 »

A simple Sound library like:
1  
2  
3  
4  
5  
6  
Sound mySound= new Sound();//create new sound
mySound.load("/bang.ogg");//load sound many different file types
mySound.play(23);//loop 23 times
if(mySound.isPlaying()==false){
//do something
}



Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #57 - Posted 2013-10-08 20:49:26 »

The syntax would just be a function name? How that looks horrible to you, I don't know.

cout(string);
coutf(string, ...);

Then again, I would just name them print/printf. Either way. That's just as clean as any method.
And what can those operators do that you can't do in a function?

Either way. It's preference. I'd prefer a function. You'd prefer the operators. This thread is about what we would like. (Though, in Java, but that's beside the point).

That's not (in C++ land) equivalent functionality. The use of an operator allows for the conversion to string to be overridden per-type in a non-member function and in a way that decouples it from both the stream code and the type that's being output.

Java gets around this by saying "everything is an Object, and all objects have toString()". Even then it's not functionally equivalent since it tightly links the formatting of an object to the type's definition (which is not always desirable). And only works because the language has an implicit understanding of how + works for strings and how that is mapped into a toString() call. ie. it's a single specific case hardcoded into the language, whereas the C++ streams system is constructed entirely with language features available to any developer.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline BoBear2681

JGO Coder


Medals: 19



« Reply #58 - Posted 2013-10-08 21:39:09 »

Getting really off topic here, and maybe this is simple, as I haven't really touched C++ in ages, but...

One advantage printf() seems to have over e.g. std::cout is localization, particularly positional parameter substitution.  For example, if I have a message template like so:

English: "Hello, {0}!"
Other-Language: "{0} xcvlxcvj!"

It's easy enough to handle this with a printf call:

1  
printf(template, param);


But how is this sort of thing handled with C++ streams?
Offline DrZoidberg

Senior Devvie


Medals: 17



« Reply #59 - Posted 2013-10-08 21:45:39 »

Would be nice to have string interpolation in Java.
Pages: 1 [2] 3 4
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

PocketCrafter7 (14 views)
2014-11-28 16:25:35

PocketCrafter7 (9 views)
2014-11-28 16:25:09

PocketCrafter7 (10 views)
2014-11-28 16:24:29

toopeicgaming1999 (76 views)
2014-11-26 15:22:04

toopeicgaming1999 (67 views)
2014-11-26 15:20:36

toopeicgaming1999 (16 views)
2014-11-26 15:20:08

SHC (30 views)
2014-11-25 12:00:59

SHC (28 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (28 views)
2014-11-24 19:59:16
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!