This looks very promising. Anyone care to evaluate ?
Hm, Blah^3 would appear to be on a religious rant sort of trip there. Discussion is kind of about how to make a lot of other people happy other than oneself too. I have very little use for operators because I don’t do 3D at the moment (and make no mistake I’m not talking about operator overloading, just the ability to use methods like operators, no confusion, no weird symbols, nothing difficult to work out).
And the exception argument is already an enigma within the JVM - why are half of the exceptions that can be thrown unchecked? Because they clutter up the code? Perhaps we find now, after, hm, 8 years or something intensive use that checked exceptions just clutter up code too? How come .net has done away with them? Is it hurting them? I rather doubt it. I think after all this time I’ve pretty much come to the conclusion that checked exceptions do not help application development to be any more correct than it was before as it is trivially bypassed. And no, you can’t sack me for doing it, or anyone else who works for you, because you almost certainly do it yourself. If you start thinking in terms of humans being the most important part of the programming equation rather than God then it pays to understand human motives and reason and emotions and not make people do things that they don’t want to do because they will just find a way not to do it and that includes defecting to .net, ignoring checked exceptions, changing the language, using scripting languages, etc.
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. But bugger if they don’t have a habit of making methods private that are full of useful code. I have to dig up the fecking source (if I can get it - or decompile it at worst), make the method public, recompile the code and build a jar, and then carry on with my hackery. Very annoying and totally counterproductive.. If OOP was meant to make software engineering easier, it’s failed.
Cas 
[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. But bugger if they don’t have a habit of making methods private that are full of useful code. I have to dig up the fecking source (if I can get it - or decompile it at worst), make the method public, recompile the code and build a jar, and then carry on with my hackery. Very annoying and totally counterproductive… If OOP was meant to make software engineering easier, it’s failed.
[/quote]
You’ve got to be kidding! :o
I don’t even know where to start…
Ask yourself what the purpose of those modifiers are, and what they prevent you from doing, when you want to do it. Then ask why anyone should prevent you - the user - from doing something.
Cas
For just one example, they hide implementation details
[quote]and what they prevent you from doing, when you want to do it.
[/quote]
They prevent me from coding to those implementation details, which is always a bad idea.
[quote]Then ask why anyone should prevent you - the user - from doing something.
Cas
[/quote]
Because it increases the dependencies between components (is cohesion the term I’m grasping at here? edit: nope, it’s coupling). Which is bad.
True, a bad design can hide functionality that you want to get at, but that’s down to the bad design rather than access modifiers.
This is the first time you’ve said something I’ve substantially disagreed with. Is it a sign of the coming of the end times? Everyone be on the lookout for rivers of fire, plagues of locusts, cats and dogs becoming friends etc.
edit: initial post was from the wii, and so touch on the terse side
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.
How about having something like the following:
public:
void methodA() {...}
void methodB() {...}
//more public stuff
private:
void helperA() {...}
void helperB() {...}
int myPrivateVariable;
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:
//#####################################################################################
So I take the simple way out and just don’t use the first layer of indentation. But it screws up the way Eclipse indents the code sometimes, and then I have to fix it.
And why have end brackets for classes? Why not just have something like the following:
#public class myClass extends someOtherClass implements happyFaceInterface
//a bunch of non-indented code here
In the off chance that you define more non-inner classes in the same file, you can just have another line with a # sign. The end bracket is completely superfluous because all code is in a class except for the package and the imports at the top.
So I propose using the # (or something else) for class definitions instead of bracketing them. I don’t think that’s going to happen, but it would be convenient for me. The point is primarily to change the way people write code so that less space is wasted by useless indenting.
If you’re having problems with too much indents, you’re doing something wrong imho. :-
Let’s keep things consistent, and use brackets for code blocks like class declarations…
[quote]Ask yourself what the purpose of those modifiers are, and what they prevent you from doing, when you want to do it. Then ask why anyone should prevent you - the user - from doing something.
[/quote]
I honestly have no idea what’s on your mind other than going back to old-school spaghetti code.
To me it’s perfectly clear why I want those modifiers. It’s basically what bleb said.
Maybe something like this would be more consistent with the language:
private {
int somePrivateInt;
boolean isNotForAnyone;
}
public {
float noSecrets;
int lookAtMe;
}
EDIT: except that we have something like that for static{} which means something else… :-\
[quote=“princec,post:14,topic:29268”]
… not anywhere I’ve worked. Who does that!?
use udbble space for indents, and don’t raise the cyclomatic complexity beyondsomething stupid.
as for brackets defining your code block, there great and the last one you don’t type anyway not in any ide I know ######### don’t make any sense.
yeah!
e.printStackTrace(); -> logger.error(e);
;D 
e.printStackTrace(); -> throw new RuntimeException(e.getMessage());
: :-X :
Then at least do:
e.printStackTrace(); -> throw new RuntimeException(e);
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.
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.
This excellent article explains the correct way of using checked and unchecked exceptions: http://dev2dev.bea.com/pub/a/2006/11/effective-exceptions.html
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.
Here is an article about the dark side of Java 5 features: http://www.jroller.com/page/vprise?entry=java_5_language_changes_were
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.)
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.
It was a joke and discarding the cause was the best part of it actually I consider rethrowing checked exception as runtime exceptions the root of all evil (at least similar)
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.
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.
there’s an actual contract for that in place, it maybe not be harshly enforced but it’s there.
open for extension, closed for modification comes to mind
hows every one on http://tech.puredanger.com/2007/01/26/java7-property/
I haven’t looked at it closely, I’m still forming my opinion.
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