Re: 7.0 wishlist?

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

The primary purpose of unchecked conversions is to facilitate migration to generics at disparate times.

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.

See <http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/444250a94b1020c6/d1a9b67ddd23f8f9?#d1a9b67ddd23f8f9> for the start of a thread in which I discussed this particular issue at length, and why I feel that your response is inadequate. Other postings on that thread reveal my opinions on operator overloading more clearly.

In particular:
* You cannot assume that any operation is commutative. Even for stuff like multiplication (matrix multiplication is, in fact, non-commutative), the LHS could be causing a mutation and therefore need to be evaluated before the RHS.
* "Inverting" operations is often perilous. Dividing by a matrix is conceptually equivalent to multiplying by its (pseudo)inverse, but inversion is one of the worst things one can do where solving a matrix equation is preferred.

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.

The main thread on which I discussed this was titled Java 7 Features. You now have a link to said thread, so I need not repeat the several dozen posts anymore.

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.

The authority is by the people in charge of the languages--in Java's case, the JSR expert groups. No language exists in a vacuum; note that Java's generics feature is roughly based on C++'s templates, at least in terms of syntax.

LISP is not close to Java (they have completely disparate influence trees), but something like, say, PHP (which shares a moderate influence with C, C++, and Java) is closer.

~= perhaps, for equals()?

o_O ... that makes no sense in terms of syntax.

But it is awkward and verbose.

To make it less verbose than my example requires several orthogonal steps:
1. A constructor that takes an array of pair objects.
2. A "neat" way to create pair objects.
3. Reduced verbosity in array creation expressions.

If either of the last two does not happen, the creation will end up being more verbose.

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

In my experience with languages such as C and C++, this does not happen as often as you think.

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.

So it does. I think the original statement was supposed to be something like this:

"... our reactions to basic proposals before repeating the proposal without adding anything new to say."

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.

It's not that I don't like them, it's just that no one bothers to add anything new, so it's the same bloody stuff being repeated once every month or so. Operator overloading and closures in particular

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.

I would expect that someone should avoid repeating points belabored to death before posting something. It doesn't take much effort to determine if what you are about to add is something that has been recently discussed in grand detail.

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

That has been discussed elsewhere in this thread.

Indeed, let us move it thither.

--
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
.

Relevant Pages

  • Re: 7.0 wishlist?
    ... The primary purpose of unchecked conversions is to facilitate migration to generics at disparate times. ... Operator overloading is principally used for mathematical constructs. ... It is not the job of the language designer to enforce against every conceivable misuse of a language feature, least of all to do so by simply refusing to add any features at all for fear that they might otherwise be abused. ... it is difficult for Java to not have chosen C++ syntax for various reasons. ...
    (comp.lang.java.programmer)
  • Re: 7.0 wishlist?
    ... my class would effectively implement dozens of interfaces that I didn't know exist and whose contracts I am probably violating. ... 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. ... 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. ...
    (comp.lang.java.programmer)
  • Re: 7.0 wishlist?
    ... My guess is that you're dead-set against operator overloading, probably at least partly for emotional reasons, and that is why you refuse to actually seriously read and consider proposals for them, and furthermore why you respond with mild but noticeable rudeness whenever the subject comes up here. ... Pointing someone to a canned response is not a discussion, and the purpose of this newsgroup is discussion, not shooting down everything anyone says with prefabricated, non-negotiable responses. ... Even if you actually sit on one of those expert groups, you are one voice among many, and therefore pretending to be somehow "in charge of Java" is deceptive as well as rude. ... Launching a rant sprinkled with personal attacks against someone for mentioning them in your presence is not appropriate, adult behavior. ...
    (comp.lang.java.programmer)
  • Re: What a pity that Java not Include Operators overloading,Wake up
    ... Java start to support Operators Override in new nice way. ... If operator overloading is controversial, creation of new operators is even more so. ... At least '<<' has a clear basis point for code (it shifts characters to the left), but what the heck is `a $ b' supposed to mean? ... Your proposal also involves using alphanumeric sequences as potential operators, ...
    (comp.lang.java.programmer)
  • Re: D gets it right
    ... > You shouldn't be repeating the same code in a dozen places anyway, ... easy to not leak memory, and bad code is easy to spot. ... > the try...finally code and GC of Java over the manual memory management ... >> I prefer languages where simple code can be correct code. ...
    (comp.programming)