Re: 7.0 wishlist?

Joshua Cranmer wrote:
How so?

How many interfaces are there in core Java code alone? With these change, my class would effectively implement dozens of interfaces that I didn't know exist and whose contracts I am probably violating.

I find that unlikely, since method names and signatures would have to match "sufficiently well" (same name, contravariant argument types, and covariant return and throws types).

Even if it did, it would be understood that only by putting "implements Foo" on a class is its author making any claims about their code adhering to Foo's contract. People use it as a Bar, if it has Bar's methods but no "implements Bar", at their own risk.

Just as they make unchecked casts of generic collections at their own risk right now, and prefer to avoid doing so whenever possible.

No, it is not, and I will thank you to stop gratuitously insulting me. You, sir, have an attitude problem.

Then how do you propose to add such features as LHS-based operations, like 2 * matrix?

For operations that are ... what is the term? Commutative? It can look for the "plus" method in the RHS if the LHS lacks it. Alternatively the programmer has to do matrix * 2 instead -- big whup.

For division and subtraction, it would have to either give up or look for the RHS to have plus and negated, or times and invert. Then RHS.negated().plus(LHS), or RHS.invert.times(LHS). Sometimes that might be inefficient. Sometimes it might even throw exceptions -- 2/matrix would probably try to invert the matrix, then double every cell. If the matrix isn't invertible (and it may not even be square) the invert method will presumably throw something, or return null, which would make the .times throw NPE.

But we already have math operations capable of throwing ArithmeticException, so...

I'm sorry. I assumed you had been a denizen of this newsgroup for a while and therefore had seen my copious commentary of operator overloading in the past year or two (which has come up in at least three separate threads).

A quick Google Groups search should have disabused you of that notion. :-) Not that it matters. If you've previously expressed distaste here for operator overloading, that really should not mean that everybody else has to refrain from discussing the subject here on pain of being personally insulted by you. We should remain free to discuss what we please, even topics that you might dislike, so long as they pertain to Java. Given that you are not in charge or otherwise elevated to some special status here that gives you the right to set topic rules, anyway, and I strongly suspect that that is the case.

In simpler language, if you don't like operator overloading being discussed here, perhaps you should go start up comp.lang.java.programmer.moderated, with yourself as moderator, and say "No discussions of operator overloading allowed" in its charter?

Except many other languages use == as equivalent to the equals method and === as equivalent to Java.

Other languages are irrelevant.

They are relevant.

They are irrelevant. We are discussing Java. If languages were not allowed (by who? nobody has this authority anyway) to be too different from one another, we'd probably all be sitting here discussing Java 7's implementation of cons, car, and cdr for Chrissake.

Anyway, if you have a better suggestion, go ahead. = is right out because changing the assignment operator to say := would break pretty much every piece of existing code out there.

~= perhaps, for equals()?

You're joking, right? It makes an unnecessary temporary collection. In fact, all the collections really ought to have constructors that take an Iterable and just iterate over it. In many cases, they can be implemented in all of two lines of code:

This is the first suggestion I've seen that would have a very strong chance of making it in (although not the first worthwhile one, others were also worthwhile).

A left-handed compliment, at best.

There's also this for the last one:
new HashMap() {{
this.put("key1", "value1");
this.put("key2", "value2");
}};

Now you're making a whole extra class. How efficient.

Doesn't require any changes to existing libraries, the JLS, and the JVM.

But it is awkward and verbose.

It's slightly more verbose and no easier to scan for.

It's not something I'll belabor, but most people would probably prefer the second form merely because it obviates that x is an Object and not a boolean.

Usually that would be apparent from context. Quite often, the very preceding line will have resembled "x = foo.get("string");".

I have many problems with closures, and so do many others in this newsgroup. My (and others') complaints are well-documented on this newsgroup. I cannot feel any sympathy for you if you did not look to gauge our reactions to basic

?

Your sentence dead-ends in mid-air.

And once more with emphasis, if you do not like discussions of closures you're free not to read them. Launching a rant sprinkled with personal attacks against someone for mentioning them in your presence is not appropriate, adult behavior.

In a weird way, you remind me of the religious prudes that freak out over people kissing in public, or over television programming they can avoid with the click of a button on their remote control.

I didn't look to "gauge your reactions" because I shouldn't have to. I should be able to expect civility so long as I have been civil myself, and so long as what I write here is on topic here, even if you disagree with my opinion.

Unfortunately, apparently I should expect rudeness instead in those circumstances, not even just from you but from several people here.

Courtesy is dead; long live courtesy.

In your humble opinion.

Knowing how enums are implemented, you'd basically have to change nearly every aspect of implementation. I don't see how you could make this possible:

public enum SomeEnum {
A { void foo() { "Foo!"; } },
B { void foo() { "Bar!"; } },
C { void foo() { "Ugh!"; } };
abstract void foo();
}

public enum Enum2 extends SomeEnum {
A, B;
}

since SomeEnum$A, SomeEnum$B, and SomeEnum$C inherit SomeEnum.

That has been discussed elsewhere in this thread.
.