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.

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)

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.

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

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.

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.

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 variables3. operator overloading - all overloadable operators that c++ currently provides4. 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 destructor5. pointers6. 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.

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

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?

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.

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.

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.

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 variables3. operator overloading - all overloadable operators that c++ currently provides4. 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 destructor5. pointers6. 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.

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!

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.

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.

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