Re: 7.0 wishlist?

Harold Yarmouth wrote:
Joshua Cranmer wrote:
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.

No, unchecked conversions have other, commonplace uses. Frameworks/reflection, for starters, and there are other cases where they can't always be avoided because the compiler sometimes just isn't smart enough to prove everything the programmer can about what types can actually be occurring where.

Which is to facilitate migration of generics. Granted, the complete migration is impossible at this time, but such unchecked conversions will be unnecessary with reified generics.

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.

Hey! You guessed wrong! I actually support operator overloading. I've just given a lot of thought to the issue so I've found significant hurdles to implementation. Your proposals are not adequately addressing these hurdles.

Sorry, but if you want to explain your reasoning, you'll have to actually explain your reasoning, not fob me off with some URL that's so long it won't work (with this news software at least) anyway.

I'm trying to save bandwidth and breath.

Other postings on that thread reveal my opinions on operator
overloading more clearly.

[ Snip several paragraphs of information all resulting from an incorrect assumptions. ]

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

The contract for .plus should include commutativity. That leaves .times. There, one could specify that if times is noncommutative there be a .leftHandedTimes (or whatever name seems most suitable) that reverses the roles of LHS and RHS.

Operator overloading is (or at least should be) principally used for mathematical constructs. There are several structures for which operations are not commutative. Note that, in programming, even regular addition is not necessarily commutative.

a + b == b + a, right? No.

((byteArray[i++] & 0xff) << 8) + (byteArray[i++] & 0xff) is no
(byteArray[i++] & 0xff) + ((byteArray[i++] & 0xff).

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

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.

You're making assumptions which don't pan out. Study some abstract algebra and learn that some operations are not invertible.

I'm sorry. I assumed you had been a denizen of this newsgroup for a while

A quick Google Groups search should have disabused you of that notion.

The main thread on which I discussed this

is not relevant to the present discussion. As I have already indicated, I am not here to argue with canned replies. I am here to have civil and intelligent discussions with educated adult human beings.

It's repeating the same thing over and over again. As I said, I do not wish to repeat myself when it adds nothing new. That would make me a politician.

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.

But this was not mandatory. It could have been done differently; it just didn't turn out to be.

Technically speaking, the United States /could/ declare war on China tomorrow. Probably won't, though. Practically speaking, it is difficult for Java to not have chosen C++ syntax for various reasons.

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

So, some things should happen before other things. This is the substance of your argument that none of them should happen at all?

As I see it, all three would have to happen for any one to be sufficiently valuable to warrant consideration for inclusion. You then have three distinct features which will probably not live on their own but are not sufficiently related to be wrapped up as one feature.

In my experience with languages such as C and C++

Your experience with "languages such as C and C++" is not relevant. We are discussing Java. Your experience with Java is thus the only thing along those lines that would be relevant.

You are discussing inclusion of a C/C++ feature. My experience with the feature in C/C++ has a very high chance of mapping to what it would be in Java.

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

So your objection is now that I was *unoriginal* in some way?

No, my objection is that you've added nothing to the debate. There is sufficient material to build from, it wouldn't be hard.

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.

If that's your opinion, then you should just ignore the subject whenever it comes up. Attacking everyone who wants to participate in such discussions, simply for doing so, is inappropriate behavior and even, I'd argue, an affront to the concept of free speech.

I'm trying to help you by letting you do something: add value to a currently valueless debate. Maybe if I can clue you in enough, I can finally give you the help you need...

I would expect that someone should respect the right of the people to peacably assemble and discuss Java programming here. If some people here wish to have a civil, level-headed discussion of operator overloading, I see nothing in the newsgroup charter to forbid it, or to justify your hostility towards them for doing so.

Pedantically, we're not discussing Java programming. We're discussing Java features.

[ More aggravating paragraphs based on a faulty assumption ]

As I said, I don't hate operator overloading. I'd love for it to be included. It's just that your proposal has flaws for which you have not found, nor (apparently) seek to find, fixes.

--
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?
    ... Other postings on that thread reveal my opinions on operator overloading more clearly. ... The main thread on which I discussed this was titled Java 7 Features. ... 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. ... I would expect that someone should avoid repeating points belabored to death before posting something. ...
    (comp.lang.java.programmer)
  • Re: operator overloading
    ... Mark Space wrote: ... I don't find any document that say if the operator overloading will be ... a new feature of the Java 7 ...
    (comp.lang.java.programmer)
  • Re: operator overloading
    ... josh wrote: ... I don't find any document that say if the operator overloading will be ... a new feature of the Java 7 ...
    (comp.lang.java.programmer)
  • Re: operator overloading
    ... josh wrote: ... I don't find any document that say if the operator overloading will be ... a new feature of the Java 7 ...
    (comp.lang.java.programmer)
  • Re: operator overloading
    ... josh wrote: ... I don't find any document that say if the operator overloading will be ... a new feature of the Java 7 ...
    (comp.lang.java.programmer)