Whats “fancy” code? ???
[quote]So in essence what I’m saying is: anything that promotes reuse is good. Anything that hinders it isn’t helping me.
[/quote]
Sorry but I still fail to see how private/protected/public keywords hinder reuse :-\
That’s because that information is private. ;D
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.
Cas 
blah blah another example of a bad programmer writing bad code blah
Your point being?
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
[quote]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”.
[/quote]
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.
My point being, I have work to do, and this got in the way. Nothing I could do about it. Can’t exactly write to JIDE and ask them to sack the guy who put a private modifier in can I?
Cas
Couldn’t just replace the image in the JAR maybe…?
Kev
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 
yeah yeah, I read your opinion on aop, I’ll be running now ;D
[quote]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”.
[/quote]
…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.
Getters and Setters are needed in many cases.
Why?
-for validity checks
-for property change notifications
-to add a layer of protection so you can keep the same interface (contract?) but change the implementation as needed
I’m generally against the buzz around adding “true” properties to the Java language… I just don’t see the problem with the way things are now. writing getters and setters coudl be tedious - if anyone still does that by hand… IDEs generally do it for you, and then of course you fill in the extra bits that a built-in property feature can’t handle anyway (e.g. range/security checks, logging, etc.).
Making everything public may let you patch a library… but then it cripples the library author’s ability to make changes that don’t break your code.
BTW for #4 in Cas’ original list… Did anyone catch the recent library mentioned on java.net https://nlink.dev.java.net/. It looks very interesting to me.
Well why can’t Java syntax be made that allows you to silently intercept direct variable accesses and pass them through a setter/getter. Then we get the best of both worlds.
AKA properties in C#
I’m starting to think that MS made a really good decision to separate out the bytecode / CLR section of .Net from the actual language specifications (eg. C#). That way everyone can go off and make their own crazy modifications to the actual languages without forcing them down everyones throat. You could have Java++ with operator overloading, proper const, null checking at compile time, etc. At the moment we get a half-way version of this where people stick with a particular Java version instead.
why cant ide’s do these things?
Er, they can, that’s what this thread is all about If we could tweak the language a bit, what would we do? And then somebody might whip up a compiler for it in Eclipse and see how it fares.
Cas
shudder operator overloading is a path to the darkside!
Any time someone has a bright idea on how to obfuscate the meaning of the java syntax,
I think they should be forced to go back to school and teach the java syntax to programmer noobies for a week!
Not really… then you get mysterious side effects when you thought you were doing a simple assignment. Also, how would you implement the setter without making it infinitely recursive?
Getters and setters are part of a pattern that is so well recognised that it is natural for Java programmers. Changing that isn’t really helping anyone. IDEs do most of the typing for you,so saving a few keystrokes is almost 100% irrelevant. It also is a great feature to be able to type myVar.set and get a pop-up list of all the things that I’m allowed to set on that class. What happens to that awesome auto-documentation showing super timesaver when suddenly I’m forced to wade through everything because there are no setters anymore?
Nobody commented on NLink. I thought it was a really great way to do JNI and I think there would be a much greater pay-off if something like it, or better, was integrated into Java to improve the whole JNI experience.
Integrated directly into Java would be great.
Cas
Wait a minute, you are NOT encapsulating anything by adding a getter/setter. Getters/setters don’t give you magically “encapsulation” by their mere existence alone. How can you be hiding something and providing a getter/setter at the same time? Is this a quantum computer? This is like saying the bit is 0 and 1 at the same time, you are going down and up the stairs at the same time, you are in and out of the house at the same time!
If you want to do validation then a method is the ideal place for it, since it will perform some logic. Besides, with properties the developer can’t tell if that is a public field or a private one, it means, he won’t be able to understand the code just by looking at it, because it might call a method or not.
This is just overloading the meaning of the operator ‘=’, the same problems of not being to tell what is going on will happen. Operator overloading? That’s how it should be called.