This has little to do with what princec was saying, but I really don't want to have my crappy little helper methods exposed for use by anyone. I would like to type less though.

The problem with this is that it could make it marginally harder to tell which methods are public/private/whatever while you're programming, but an IDE could use different-colored text or have some kind of marker or something.

There is another thing that annoys me even more, but it's more a matter of style. The "normal" way to write a class is to indent every line inside of the class, but that uses up alot of my valuable screen space (which sometimes causes my expressions with long variable names to take up multiple lines). The only information the first layer of indentation provides you with is that you're not writing package or import statements and so that you can see the not-indented start and end points of . Presumably, you can tell the difference between those statements and the actual code.

If you want some kind of marker to make the class definitions stand out more without the indentation, just use a comment like the following:

1. I'd add "NOT NULL" as a modifier to variables, and get the compiler to assert whether something could possibly be null and complain. Why? Because I'm sick of having to assert whether something's null or not when a compiler should be much better at doing the job than me.

I would like this as well. I like the way @NotNull works in IDEA, and I would want the VM to do runtime null/not-null checks automatically. I've heard there is a JSR about adding more annotations (including not null) to the standard Java API, so I'm quite sure that we'll get this sooner or later. The only problem I see, is that having annotations in front of every method parameter makes the code a bit messy.

2. I'd remove checked exceptions. Why? Because they don't actually appear to make it any easier to code correctly. Exceptions always get caught by the VM and are handled correctly anyway.

I oppose. What I would do instead, is improve the way that Java API uses checked exceptions. Checked exceptions should only be thrown, when it is possible to recover from the exception (in other words, it is part of the business logic). In case of faults (such as I/O errors and programming mistakes), only unchecked exceptions should be thrown.

Oh I just remembered one of the most important things I left off the list: operator declarations, which enable you to declare static methods as operators, eg. the much fabled dot operator for Vector3fs:

If anything, I would want to increase the use of access modifiers, but I don't necessarily want to have to type them every time.

I'm against all syntactic sugar, which does not improve the readability of the code. Modern IDEs take care of most of the typing, so verbose code is not any slower to write. When looking at a code, it should right away be clear what the code does, but if things such as operator overloading are used, you can't really know what the code does by just looking at one spot.

The "normal" way to write a class is to indent every line inside of the class, but that uses up alot of my valuable screen space (which sometimes causes my expressions with long variable names to take up multiple lines).

Get a bigger screen. On a wide-screen 24" (1920x1200 resolution) you could have very long lines, and they would still fit on the screen. (Except that it's hard to read long lines, so you better fix your code if you have deep indentations.)

6. I'd add the "const" keyword back into the language, and maybe enforce that at VM level too. Why? Because it's easier than all the of alternatives!

Could you explain what you meant? What I understood, is that it would be possible mark methods with "const", and then if a reference to that class is also marked "const", it would be allowed to call only the "const" methods. This might help to avoid accidental modification of a mutable object. I'm not sure how useful it would be.

When it's a checked exception that you can't recover from, throwing a RuntimeException is a perfectly good solution.

Yeah you are right. I was a bit rash with my statement. But at least one should throw a concrete RuntimeException subclass (where possible) with a descriptive message text and a correctly initialized cause.

I'm against all syntactic sugar, which does not improve the readability of the code. Modern IDEs take care of most of the typing, so verbose code is not any slower to write. When looking at a code, it should right away be clear what the code does, but if things such as operator overloading are used, you can't really know what the code does by just looking at one spot.

IMHO operator overloading would improve code readability by a great margin. Especially when it comes to vector and matrix math the current situation in java is a pain in the a... I also don't see any difference between operator overloading and method overloading. It comes down to the discipline of the coders to not misuse operators. Nobody stops you to overload maybe the hashCode()-method to e.g. return the number of times an object is used - but nobody would do that.

I'm not sure why anyone in here is opposed to operator declaration - notice it's not operator overloading as in C++, which involves redefining crazy symbols like * ~ !, but simply declaring methods that are designed to be used as unary or binary operators.

I'm not sure why anyone in here is opposed to operator declaration - notice it's not operator overloading as in C++, which involves redefining crazy symbols like * ~ !, but simply declaring methods that are designed to be used as unary or binary operators.

Yes, it's not as bad. And, actually, since I've never programmed in a high-level real-work language that allowed user-created-operators (done it in scripting languages and in odd niche languages, never anything mainstream) I ought to be a lot less reactionary, since it could be a lot easier than I expect.

Sorry for the strong reaction, but I'm partly conditioned by e.g. the reactions to your original structs proposals, where the similarity of what you were suggesting to something else (that was also popular) blinded many people to the specific details of what you were actually saying . When people want something, they often see what they want to see, not what you're actually saying.

I would like to experiment with operator dec and see how it worked out in practice. In theory, once eclipse has support for it, so that I could mouseover the operator to get a description of it, it *could* be no more disruptive than ADT's are now.

I'm not sure why anyone in here is opposed to operator declaration - notice it's not operator overloading as in C++, which involves redefining crazy symbols like * ~ !, but simply declaring methods that are designed to be used as unary or binary operators.

Well, that makes more sense. At least then it would not be confused with the basic arithmetic/bit operators.

The operators would at least require color highlighting in IDEs, or a different syntax. Otherwise it might be possible to mix variables and operators (i.e. is "dot" an object or an operator - maybe "vec1" and "mul" are unary operators, "vec2" is a binary operator, and "dot" and "4f" are variables).

I don't like the syntax "foo.property = value", but automatically generated getter and setter methods would be useful. For example, fields could be marked with a @Property annotation (optionally taking parameters: read-only, write-only, property name, visibility, events etc.), and the compiler would generate the code for simple getters and setters. This would keep compatibility with legacy code, would allow customizing the getter/setter implementation without changing the API, and would provide better documentation for properties (for example, the javadoc for getter and setter would be copied from the javadoc of the property field).

Having an object representation for properties would also be handy. However, it might be best to avoid adding new operators such as ->. Maybe this could be done with some new API.

I am absolutely against adding crazy new meanings for squiggly symbols... one of the reasons AOP makes me shudder is because it looks like gobbledigook.

What I really want, I suppose, is ways of saying things that we do now, but with much less typing, such that it's easier to just glance at something and know that it works in a particular way. If for example the "property" keyword were added, we'd know that accessing a property went through the defined get/set methods if defined. I suppose that means interfaces are going to need to be able to define properties too.

I quite like the idea of being able to embed XML snippets directly in sourcecode (there's an RFE for that for Java 7).

I also like the suggestions of block modifiers, such a simple thing to implement in the compiler:

The only thing i would like to see expanded was algebra primitives: tuples, points, vectors, matrices, quaternions, complex numbers. With the usual primitive operations optimized to take advantage of the hardware this could explore the advantages of using a jvm over native code.

I'm not sure why anyone in here is opposed to operator declaration - notice it's not operator overloading as in C++, which involves redefining crazy symbols like * ~ !, but simply declaring methods that are designed to be used as unary or binary operators.

Cas

What's the problem with that? It's wrong to deprecate a language to babysit bad programmers.

3. I'd remove the need to make casts where the type can be inferred. Why? Because when it's obvious that you're attempting to make a cast, why should you have to type it?

Kim Bruces book "Foundations of OO Languages" despite the name, is actually about types and oop languages. He says the main obstacle to ML style type inference in OO languages is the incomplete concept of types as classes/data abstractions. In practice the difficulty in inferring types in current oo languages (ie java) is inheriting classes and overriding methods. Method selection is static at compile time. Plus, over riding a method in a subclass can destroy the meaning of the method if it's used in the super class.

Typing and type inference is not trivial.

Quote

Here's another controversial suggestion: ditch public/private/protected modifiers. All they do is make it harder to modify OO code to do what you want it to do. Most of the time, I want to modify someone else's library in some way using extension, and quite often that involves hackery because I want to use that code in a way they just plain didn't realise.

This gets my vote as the number one thing wrong with oop: Encapsulation and inheritance impede code reuse. Period. (imho).

This gets my vote as the number one thing wrong with oop: Encapsulation and inheritance impede code reuse. Period. (imho).

Quote

in a way they just plain didn't realise.

if they didn't realise it, then it wasn't designed for it and thus your breaking contracts sooner then later, which kills maintainability and creates another shit load of problems OO is about objects and methods and what they represent not the instructions contained in it.

the cases that you can sum up that aren't covered by the earlier statement are cases of bad design.

I think that nearly everybody has realised in practise that OOP isn't about objects and encapsulation, it's just another take on trying to write as little code as possible to do the most work, because at the end of the day, that's all we really care about. Why do we think scripting languages have taken off so fast suddenly? Less code for more work. Little imposition about somebody else's ideas on your own ideas.

I mean, it's all very well saying "Yes but we're software engineers! I write libraries for other people to use!" But when that other person is me and I can't bloody override something in your library because it's private and hence can't make the bit of code working that I'm working on right now it just annoys the hell out of me!!

I suspect design-by-contract is actually what's really needed, not this notion of "private" code which isn't really private...

I think that nearly everybody has realised in practise that OOP isn't about objects and encapsulation, it's just another take on trying to write as little code as possible to do the most work, because at the end of the day, that's all we really care about. Why do we think scripting languages have taken off so fast suddenly? Less code for more work. Little imposition about somebody else's ideas on your own ideas.

Yeah and everytime the developer responsible for this code leaves the company, nobody can fix or change anything because nothing is encapsulated and you never know what side-effects the code has.

This is bad, if the code is inhouse, but disastrous if the code was sold to a customer. They come back and say "hey we just need this little feature" and you take down their whole site while trying to implement it in the timeframe, the customer will pay for. In the end you have rewritten the whole application and only get paid for the added little feature. I've seen that very often and have been there myself. Scripting languages are extremely dangerous for anything else but minimal scripting of a well designed and encapsulated system.

I mean, it's all very well saying "Yes but we're software engineers! I write libraries for other people to use!" But when that other person is me and I can't bloody override something in your library because it's private and hence can't make the bit of code working that I'm working on right now it just annoys the hell out of me!!

I once had the opportunity to use a library where every method and field was public or protected. I was very glad, because every little bug I found could be easily fixed by overriding the protected methods and directly accessing the fields to produce the correct result.

That was five years ago.

Now I still have to use the five years old library with it's five years old features and it's five year old architecture shortcummings. In the meantime there is a more faster, better designed version out there with a lot of nice features I would like to use, but I can't because exchanging the library would mean to rewrite the whole code, that interfaces with the library, because of the missing encapsulation and separation in the first place.

OOP in practice should be about objects and encapsulation, because OOP should be about maintainability.

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