How would you specify method overloading priority? Like BODMAS but with methods…
So if you do:
Vec3f vec = vec1 dot vec2 mul 4f;
Which is done first? The vec2 mul4 or the dot?
DP
I dunno, presumably standardise on one convention like left-to-right association or something.
I like the properties proposal. Writing get and set methods is just plain stupid.
Cas 
maybe im stupid, but cant most of these ideas people have suggested be done inside of an ide, with macros of something, without changing the language?
I suppose the ideas are mostly about code readability and simplifying. Having a smarter IDE doesn’t make the code more readable, it might merely just save some typing.
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.
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:
private property {
int a;
String s;
float foo;
}
Much nicer than
private property int a;
private property String s;
private property float foo;
Cas
Hmyea “named operators” are certainly better than overloaded operators. But I don’t think that we really need em.
Operator overloading is usually used for stringcat, vector stuff and for trying to make C++ sorta managed.
We already got the + op with strings and we really don’t want to emulate a stone age vm. What’s left is vector stuff, which could be done with build-in vector classes (with overloaded operators).
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.
What’s the problem with that? It’s wrong to deprecate a language to babysit bad programmers.
Most of us are using Java for the productivity gain.
So?
Operator overloading decreases productivity in the long run. Trading some typing work against clarity is a bad trade. Do you really want a language where x+=5 can mean something completely random?
But it can also increase clarity if well used. With my idea of primitive vectors:
vec v1 = (1,1,1);
vec v2 = (0,0,1);
mat m = ((2,0,0),(0,2,0),(-1,-1,1));
//vector add
v = v1+v2;
//scalar mul
v = v1*k
//dot prouct
v = v1*v2;
//transformation
v = v1*m;
//in place transformation
v *= m;
Compare this to the more verbose version and tell me what is more clear.
Poor programmers will always write bad code one way or another.
[quote]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?
[/quote]
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.
[/quote]
This gets my vote as the number one thing wrong with oop: Encapsulation and inheritance impede code reuse. Period. (imho).
As I said… build-in vector classes with overridden operators (like it has been done for String) could be nice.
[quote]in a way they just plain didn’t realise.
[/quote]
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…
Cas
Wouldn’t it be sufficient to have a (AOT) bytecode transformer that turns all private/default/protected access modifiers into public?
You feed it a JAR and it spits out a JAR.
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 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.
I really don’t know how you can enforce a contract without encapsulation.