Mostly by assertions, pre- and post-conditions and invariants.
Your example about the library that “moved on” that you can’t upgrade to is a bit like not seeing the wood for the trees. You mean you’d happily sit there for 6 years waiting for a bugfixed nice new version of the library rather than just be able to get in there and override/fix stuff? Crazy. We’ve got deadlines and customers!
As for the whole encapsulation argument… well, some of the biggest and best applications ever deployed are written entirely in scripting languages. Look at, for example, VBulletin. We don’t see them moaning about public/private/protected in PHP. It’s clearly a bit of a “that’s the way I was told it works so it can’t be possible to try out any alternatives”…
the in practice bit i need to further evaluate for myself, but for the php greatness argument I don’t see how that rithmes with reuse if anything I see more hack if any reuse
The server-VM tries to inline everything into everything, until it can’t do it anymore, or de-optimizes code after the usage of a method changes (like an other implementation of a class is passed to a method).
private can be inlined at the bytecode level by the Eclipse compiler, maybe the client VM gains some speed by that.
[quote]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.
[/quote]
If a programmer wants to write code, he most likely sucks.
[quote]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!!
[/quote]
If it’s open source than you can make your change (if the license permits so).
The private keyword will at least give you a hint that you’re doing something with the code that:
a) Is hackery, using the code in a way that it was not intended for and a new version of the library (or even java runtime) might (and 99% sure will) break your code again.
or
b) Is an improvement, fixing a bug or whatever, in which case you could submit it back to the authors so everyone will benefit from a better library in a new version.
I just can’t get the idea out of my head that getting rid of the private keyword will lead us back into the ‘spaghetty wild, wild west’ of old school basic or machine code programming, and that such things as encapsulation and OOP were steps in the right direction.
But I really hope I’m missing the point here :
class Matrix <T> {
@Get("rows")
int rows() { ... }
@Get("columns")
int columns() { ... }
@Get("[]")
T getElement(int row, int col) throws .. { .. }
@Set("[]")
void setElement(int row, int col, T elem) throws .. { .. }
static void main(String... args) {
Matrix<Integer> matrix + ..;
for(int i=0; i<matrix.rows; i++) {
for(int j=0; j<matrix.columns; j++) {
matrix[i,j] += 2;
}
}
}
}
Of course a public class attributes hides the getter/setter name used in the annotation in order to be backward compatible.
Further, image how java.util Collections could be unified…
Modularize the Java Language
This would be most important to me. As Steve Jobs said, Java is to heavy weight. I’d like to remove everything not contained in ‘java.lang*’ and put in into versionized modules.
I believe this would have a great impact because:
one has the freedom of choice: use java.nio + LWJGL or java.sql + org.gome.gtk, …
Maybe a faster startup time since less to load (ideally only things used be the app)
fast installation of the ‘core’, perhaps even faster than flash
Comments on few of your suggestions:
From the language side, I’d find it ok, but not necessary to have ‘not null’ objects. However, I believe it could increase performance using the value type wrapper classes (Float, Integer,…). A
@NotNull Float[]
could by mapped to a float*, in cotrast to allowing null references, I guess then it has to be a float**. As a conclusion one could use Matrix and when instanced as Matrix<@NotNull Float>, the VM could just use primitive floats.
Never thought of s.th., but it would be nice IMHO.
I second that, from the barrier thing. Also I don’t see how this could be done. VM idependantly (work the same way with SUN / IBM / APPLE VMs)…
In the case of Java, I’d think a compile time approach using ‘const’ doesn’t fit was well as the dynamic one using ‘UnsupportedOprationExceptions’; ‘const’ isn’t safe enough. I also believe, I coded right, the latter one will be efficient: The only thing the VM has to know is, that the value can never be canged, which requires every method writing to attribute to be final and throw that exception - well at least in theory.
I’m against, since the default case should not be restricting. Classes that extend one with a method containt final paramereters, can’t remove the modifier…
that argument against it doesn’t fly(again I am yet to form my opinion on implicit final, don’t we need a new keyword that says it isn’t final?, also doesn’t the jvm figure this out by it self these days?)
oh bah I was going to quote it from de jls but couldn’t find it right away, over here: http://www.jguru.com/faq/view.jsp?EID=19556 they say: Note that the use of final on a formal parameter is not part of the method’s signature. I.e., the modifier can be added or removed from subclass implementations of that method.
wouldn’t that be the same thing saying, methods aren’t virtual anymore, use virtual please…
Of course most methods aren’t overridden and most variables are treaded as they are final, but derieving classes are allowed to override or re-asign the parameter. AFAIK, the newer VM analyse this and can optimize if so. Again Java is dynamic, in a static world like C/C++ the opposite makes sense…
I really, really, really like C# properties. I am a bit in the camp that does not really like variable modifiers. More becuase they are a hassle to type. I like encapsulation, but again, writing get and sets are annoying, even using eclipse to generate them I find frustrating. So I was using C#, and properties OMG solve all these problems. You can create a fields that look like a fields but are actually objects. You could start with a normal java style variable feild and later convert it to a property with custom get and set methods (which do other code trickery behind the scenes) WITHOUT the rest of the project noticing. They just access it directly. I have noticed I can really compress my source code files using C# and still have proper encapsulation.
I think this would solve most of the things you are discussing here.
Hmm, I think you misunderstood the point, maybe I wasn’t clear: I fixed all this stuff, it works quite well, but it’s a mess nobody (but me) understands because the code fragmented (overriden “bugfixed” classes) and is interwoven with our own code (because of no clear encapsulation).
And yes, we do have customers and deadlines. That’s the reason, why we can’t fix the situation, since the customer only pays for new features he wants and not for making life easier for us developers. Even if we can convice the customer to let us “repair” the situation, they would clearly not pay us, since it was not their fault.
The point I wanted to make was: it was a major misdecision to fiddle with the libraries internals, which could have been avoided, if it was more encapsulated. This might have resulted in the inability to quickly fix things, but we could have said “that’s not possible, because…” and reported the bugs to the libraries producers. In our eagerness to quickly get a result, we’ve done work, we were not responsible for and created a dead end or at least a complicated migration path for our future work.
totally offtopic but isn’t that easily sold to the customer as bringing down maintenance costs? you can even keep it internal and simply bill the customer for the hours you saved on maintaince and compensate trough that.
Wow, did you know you can do that too with public fields? Encapsulation is not about making every single field private, encapsulation is about hiding the inner state of your object, the state it uses for performing some logic.
Either using public fields or simple getters and setters, it’s not encapsulating anything! Most people use beans as simple containers of data, why not to make all fields public? What do you think you are “encapsulating” by making a get/set?
C# has only a syntactic sugar that save a few keystrokes in the case you need to put some validation in it, but the final result is exact the same as Java’s, with the exception maybe of a few less characters. Have we become typists?
I am amazed by the misconception regarding a basic OO concept such as encapsulation, some people seem to think that just by generating getters and setters they are “encapsulating” everything! Just like that, click, click, encapsulated! A public field would make absolute no diffence in this idiotic state of things.
I don’t see why people don’t consider public fields as an alternative. OO doesn’t imply “all fields private”.
I know, I can’t figure out why people don’t get this misconception either - probably because Interfaces in Java cannot declare member variables therefore you need to include get/set etc. I like to take it one step further and say: exactly how has all this encapsulation actually helped the software industry? It’s almost like one of those mantras that people repeat over and over but without actually performing any analysis of whether it’s a good thing or not. But that is a huge argument for some other thread
Interfaces aren’t used for the “data container” type of bean. I see those beans as if they were like structs, all fields public would be acceptable.
In an interface the get/set would be needed, or some other name for methods, but the difference it is that the method would be relevant to a certain context, not mindlessly generated just because modern IDEs make it so easy.
I don’t disagree with you or Cas. I think public fields are just fine in practice. The original intent however is for the future. If I make everything only accessable via method calls, then I can add logic any time I want without screwing up code made previouslty that depends on my library.
Having said that, I still think that it is overkill, especially in one off projects like games or applications. You should really only consider those concepts more with libraries or a place in your own code where you know changes will occur.
I agree with CaptainJester. Not only should a developer know all the patterns and cool stuff and whatlike, but also when not to use it.
In a game, compared to non-gaming development, the code ‘dies’ with the project, meaning it will probably not be given out to anyone outside the team.
In non-gaming projects this is often the case or better the standard, so making it nice and architectual is important, even a must.
That’s a fallacy of the existing and very broken games development market. Throwing away code is something C++ programmers have to do because after they’ve hacked it about so much nobody understands it any more.
If you want to survive as a games developer in this new modern age you’d better learn reuse - fast. I’ve got five games that currently share about 90% of their code base as libraries. If I’d had to keep throwing away the code every time I’d never have gotten anywhere.
So in essence what I’m saying is: anything that promotes reuse is good. Anything that hinders it isn’t helping me.
@princec:
Although I wrote ‘dies per project’ it can also be valid ‘dies in company’ or similar. (Not easy to say what I mean)
A code base used only for myself or certain circumstances can/will not be as fancy as code I would write for another company.
A lib you will share on the internet would be different then what you would write for your own game. (and probably not as bloated)
I hope I am making at least a little bit of sense.
I am sure we’d all laugh about each others code at first look but after explanation we would probably admit it might be better.
