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

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

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!!

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.orb) 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

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

2. 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 ;-)

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.

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<T> and when instanced as Matrix<@NotNull Float>, the VM could just use primitive floats.

4. I'd have a fast easy native interface to DLLs that would allow you to simply load DLLs/SOs and call functions in them without writing a wrapper library. Why? Because JNI is the single biggest barrier for Java integrating with legacy code and making it hard to load and call 'em is a PITA.

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

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!

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.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

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!

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.

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.

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

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.

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.

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

Ok, here's a real world example I encountered a few weeks ago. I am using JIDE components in our biz app; there's a nifty tab pane UI in it which looks great, except that the close buttons cannot be replaced with your own icons and they look shit. Even if I had the source code to the JIDE libs I wouldn't be able to override the bit of code that constructed the close buttons because it was private. The only option is to decompile, cut'n'paste into a new class and make appropriate method protected or just edit it directly - wow, I don't think that's what the original inventors of OOP had in mind when they were talking about "reuse".

The Wikipedia entry on OOP has some interesting criticisms of OOP at the bottom, one of which being a study suggesting that it isn't really any faster to code in an OOP style than it is to code in a procedural style. As I suspected.

Ok, here's a real world example I encountered a few weeks ago. I am using JIDE components in our biz app; there's a nifty tab pane UI in it which looks great, except that the close buttons cannot be replaced with your own icons and they look shit. Even if I had the source code to the JIDE libs I wouldn't be able to override the bit of code that constructed the close buttons because it was private. The only option is to decompile, cut'n'paste into a new class and make

blah blah another example of a bad programmer writing bad code blah

Your point being?

Quote

appropriate method protected or just edit it directly - wow, I don't think that's what the original inventors of OOP had in mind when they were talking about "reuse".

OOP doesn't stop you from shooting yourself in the foot. NOr does it stop me firing incompetent coders who make things private without damn good reason

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.

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

You don't get what I am saying, nor the cool thing about C# properties.

In JAVA you have to create a get and set to encapsulate your data. A class that provides a get does not have to just pass back a reference. It could generate an object on the fly etc. Or when a set is called you could notify listeners the state has changed. In java if you make all your fields public (which I often do becuase I am lazy), you can never encapsulate the state of those objects at a later date.

However, in C# you can be lazy i.e. Create public variables initially. When your design has evoleved and you need to either refactor out the variable or replace the storage mechanism or add an event model or whatever, you simply replace the variable with a property. Properties look syntactically exactly the same as variables. So no source code outside needs to be changed (becuase of the strong form of auto-boxing C# implements), however you can write a specialized set and get for it, it does not even need to delagate to a variable for storage of anything. They are just like mini classes, so your design can evolve unhindered.

This is exactly what encapsulation is about, hiding your internals, so it doesn't matter how you actually carry out requests. C# allows you to do this at essentially the variable assignment and retrieval level, where as java can only do it at a method invocation level.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

the only examples I can think of are in the case of ui stuff(also found in swing classes, selectAllOnFocus + JFormattedTextField + JTable). weirdly enough it was my conclusion that well designed UI and UI components are just hard, and a discipline in his own right. the whole jump to you shouldn't be allowed to hide anything, I missed. Besides isn't your problem fixed with some Aop magic

Ok, here's a real world example I encountered a few weeks ago. I am using JIDE components in our biz app; there's a nifty tab pane UI in it which looks great, except that the close buttons cannot be replaced with your own icons and they look shit. Even if I had the source code to the JIDE libs I wouldn't be able to override the bit of code that constructed the close buttons because it was private. The only option is to decompile, cut'n'paste into a new class and make appropriate method protected or just edit it directly - wow, I don't think that's what the original inventors of OOP had in mind when they were talking about "reuse".

...I dunno but removing modifiers as a quick and dirty fix of some library's shortcomings seems a bit drastic to me.

I mean, I think I understand your point, but asking for removal of modifiers is like asking for a different language which requires a completely different approach of writing clean code.I'm afraid just the removal of modifiers without any other means to replace their goal will just degrade the language.

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