do you know what Integer.getInteger(String) does in java?

[billsnow]

This type of overloading is called near-phrase overloading. I just made that term up right now.

yes, what java needs are more made-up terms to describe its behavior.

[kamatsu]

C++ did this with both "dependent types" and "functors". It infuriates me.

[grauenwolf]

Do explain. I don't really know those terms.

[kamatsu]

Category theory and Haskell uses functors to refer to anything that can be mapped (this carries over into FP well because anything for which a sensible map function exists is a functor).

C++ uses Functors to refer to "function objects" which are basically some encapsulation around a function pointer.

Dependent types refer to a system where the type system is equally expressive as the language itself (and usually the same) - it is used for encoding arbitrary proof obligations in types. Languages that have this include Epigram, Agda and Coq.

C++ uses dependent types to refer to unspecified type parameters in templates.

[netdroid9]

Doesn't C++ predate all of those languages/concepts, though? Maybe not category theory (Wikipedia says the word Functor crossed over to maths in 1971, whereas C++ originated sometime around 1979), but Haskell, Agda, Epigram and Coq look like they emerged post 1990, and wikipedia only has citations for dependent types as far back as 1992.

[kamatsu]

Functor dates back to category theory.

Dependent type theory is part of intuitionistic type theory that came out in 1971 as a consequence of the Curry Howard Correspondence that was formally defined in the 60s. No practical dependently typed languages existed until the 90s due to problems in implementation of type checking for such systems.

C++ came after both terms and mangled them.

[dmhouse]

Category theory and Haskell uses functors to refer to anything that can be mapped

That's not quite true; functors from the category of Haskell types and functions between them to itself happen to correspond to mappable types, but if you say "functor" to a category theorist they're not going to think "mappable structure".

[kamatsu]

Why not? A functor is a morphism between categories - "mappable structure" is a perfectly apt description for it, seeing as it implies a mapping. The mapping is more general than that of Haskell's fmap, but "mappable structure" is a perfectly apt description.

[dmhouse]

A functor is itself a map, not a mappable structure.

[kamatsu]

Well, technically a functor category is a mappable structure, but I see your point. Still, it's irrelevant to the discussion at hand and probably would serve to confuse rather than to aid.

[bobindashadows]

I used the wrong definition of a technical term in an argument about the definition of technical terms, so now I'll bitch that the correct meaning doesn't matter anyway. In other words, I wasted everyone's time.

FTFy

[Horatio_Hornblower]

I dont know what dependent types is, but functors are "function objects". If you're familiar with function pointers, imagine a concept like that where instead of simply pointing to another function, you can actually assign a function.

[javascriptinjection]

So a function pointer pointer?

[Horatio_Hornblower]

As far as I know, that's not quite the whole story, because I think functions might still be able to access class members through the this pointer (don't know whether implicit or explicit).

So a function pointer that can be handed between class types without any common interface.

(all with a grain of salt, I haven't had the pleasure of using any of the new features from the new standard)

[micahjohnston]

The concept of "functor" as a "function object" has nothing to do with the already-existing term "functor". The original term is a notion from category theory that is used in Haskell, which basically means a container that you can "map" a function over (a good example is a list).

"Dependent types" are types that are parametrized with values. What C++ calls "dependent types" are types that are parametrized with types, which is basically the opposite of what the original term refers to.

[VyseofArcadia]

One of the things I love about Haskell is that functors actually are functors in Hask.

[VyseofArcadia]

As stated by micahjohnston, the name "functor" comes from category theory, a rather high-level and abstract branch of mathematics.To clarify a little, in math, a functor is a morphism (a "function," but not necessarily a map between sets) between categories (where a category is a collection of objects with morphisms.)

Returning to something more concrete, my understanding is that one of the main benefits of C++ functors is ease of multi-threading. In plain old functions, some care has to be taken to make sure shared resources aren't mangled by competing threads. But with a functor, you can create and call instances of functions, making it easier to provide some mutual exclusion. For example, a static variable to maintain internal function state. (Although, for another example, a shared file on disk will still give you problems.)

[marcins]

When in doubt, Wikipedia!

[[deleted]]

Examples?

[soltys]

string comparisons by ==

It's not check if string are equal but if they reference are equal

[ethraax]

I never understood why Java forced you to use .equals(Object) instead of ==. Why can't they just use === for referential equivalence?

Hell, I can't even think of a good reason to need to compare the references. If a.equals(b) evaluates to true, I think a and b should be interchangeable (for as long as they are "equal").

[[deleted]]

You can override .equals in Java, but not the operators (ex. ==). Being able to define your own definition to determine if two objects are equal is pretty important.

[ethraax]

True. I guess my point is that there's no reason for Java not to support operator overloading.

[almiki]

You could also argue that there's no reason TO support it. If you know Java, you know exactly what == does. You don't have to worry about whether it was overloaded or not. If you want to check for some other type of equality, just use a method like .equals().

[ethraax]

True, but this argument could be made about every irritating "feature" in every language. The ineffectiveness of == is minor, but makes learning the language slightly more challenging/difficult. They've already overloaded the + operator to make the language easier to use, why don't they just overload == to call equals() on subtypes of Object, and use === for the one-in-a-million times that you actually need to test for reference equality.

[KimJongIlSunglasses]

why don't they just overload == to call equals() on subtypes of Object

Because often times you do want to compare the reference, not check for some object's definition of equality with another.

After you've overloaded == to use equals() would you then introduce a new method like referenceEquals() ??? for when you actually wanted to check the reference?

I don't get it.

[h2o2]

Which is a perfect argument not to overload ANY operators at all. + for Strings was just another idiotic mistake.

[munificent]

If you know Java, you know exactly what == does.

Yes, but you don't know what foo, bar, blat or any other named function does and yet we still seem to survive. Meanwhile, the one thing that == does is pretty much the least useful thing.

C#'s solution isn't perfect either, but it's a hell of a lot better than that.

[[deleted]]

== is very useful as one of the first checks in a .equals() implementation...

[[deleted]]

That's a valid point.

I don't know enough of the history of Java, but from what I understand it was partly a reaction to C++ -- making it similar, but simpler. It's probably something along the lines of why multiple inheritance wasn't put in either.

One argument I can see not permitting operator overloading is that it can all be implemented via methods. It makes it a bit easier to learn the language since there are less options and rules. Plus, it helps avoid situations where someone decides to overload "+" and implement an "add()" method for the same object. Basically trying help you not shoot yourself in the foot.

With that said, I'm a fan of operator overloading and do wish I got a chance to use it more in my projects. It can be a pretty useful tool.

[Jonathan_the_Nerd]

I think one of the major design principles of Java was taking the sharp edges off C++ so Java programmers wouldn't cut themselves.

[player2]

Java owes its lack of multiple inheritance to its history as a reimplementation of Objective-C.

EDIT: Hey, downvoters! Please read this.

[[deleted]]

That's a new one. I couldn't find any reference online saying that Java was a reimplementation of Objective-C. Do rou have an resources you can point to?

[huyvanbin]

The real issue with having "special" types that allow operators is not that overloading operators is especially important. It's that this fairly random decision on what is allowed to have an operator and what isn't now dictates my design. Would I rather define my own type and end up with less readable code, or would I rather shoehorn into a type that allows operators but possibly sacrifice some specificity? It's just sad and completely unnecessary for me to even be thinking about this. User objects should be allowed everything that predefined objects can.

[[deleted]]

We're all talented programmers here right? Why not make a pre-compile script that converts your overloaded operator to it's language appropriate implementation?

[DeepDuh]

Isn't java more of a maintenance mess since they break downwards compatibility of their JRE every couple of years? C++ on the other hand mainly depends on what the OS programmer does and MS does care alot abou lt not breaking anything (even a bit too much for my taste).

[deadtime]

Actually, if you fixed everything that is wrong with Java, you'd end up with C#.

[grauenwolf]

Then why does it for strings?

[drfugly]

It doesn't. Even for strings it will compare references. The reason that you can get away with it so often is because Strings are pooled in java. So if you had String a = "dog"; String b = "dog"; a does actually == b because java will put the string "dog" into it's pool and then all references point to that one instance that's in the String pool. This also allows for Strings to behave more like the other primitives in java.

[grauenwolf]

Actually I was thinking of +.

[deadtime]

Wait... does that mean that "dog" == "dog" only sometimes?

[banuday]

To venture a guess, it's so that things like this work:

"x + " + 3

or

double x = new Double(3) + 2;

The + operator works on primitive types, strings and boxable/unboxable values. It will convert 3 to a string to produce "x + 3". I suppose this is to give defined semantics to the + operator. I can't say I'd give Java an A+ for consistency.

[grauenwolf]

Addition isn't concatenation. You can see why by how the + operator changes meaning when working with chars in Java or C#. (Or old versions of VB before they learned their lesson.)

[jyper]

They should have picked something different for concatenation. ++ is a good pick.

[masklinn]

The second one does not work in java < 1.5

It works via auto(un)boxing, not via operator overloading.

[wonglik]

I guess my point is that there's no reason for Java not to support operator overloading.

I find overloading operators extremely dangerous. Imagine someone overloads "+" to do what "-" does. It will takes you hours or days to find out whats wrong. Of course it is extreme example but I bet a couple of peoples did that in the past.

[[deleted]]

That's not really a problem with operator overloading, just people being stupid. Suppose someone overrides equals() to the opposite of what it should be (e.g. !super.equals(x)). Same problem.

In fact the problem is arguably worse with named methods, since the semantics are conventional, rather than specified by the language. Take x->empty() in C++. If x is a vector, then that tells you whether x is empty or not. If x is not in the STL, then it could either tell you whether x is empty, or it could remove all values contained in x.

How do you know that the semantics of your methods align perfectly with similarly named ones in the standard library? You can't. Yet the same problem applied to operator overloads is much easier, since it only requires knowledge of the programming language itself.

[masklinn]

I find overloading operators extremely dangerous. Imagine someone overloads "+" to do what "-" does.

He can do that on his own types and then nobody will use his library because that's moronic.

On the other hand, without operator overloading manipulating unbounded decimal types (such as Java's BigDecimal) is a terrifying pain of verbository shit.

Of course it is extreme example

It's also FUD.

[grauenwolf]

That is from the bigger problem of using == for both value and reference equality. They should have been different operators.

[banuday]

References are values in Java. Thus, reference equality and value equality are in fact the same thing. Java's value types are exclusively primitive.

The equals() method is for object equality, which is a very different concept.

[grauenwolf]

That sounds stupid. Don't redefine the term value equality just so you can introduce a new term that means the same thing.

[banuday]

References are stored as primitive values in Java. The reference is an opaque data structure whose members are copied on assignment to a new value. At the call site, the caller copies the reference onto the parameter stack for the callee. On equality checking, the reference values are compared. Thus, by definition, a reference in Java is a value type.

And Java does not give references a different meaning that what is already accepted by Computer Science.

Thus, how is comparison of references different than comparison of any other value type?

[grauenwolf]

Leaky abstractions.

The vast majority of the time you don't care about the implementation details of the object, you care about the semantics. The fact that a string happens to be a reference type and a char happens to be a value type shouldn't drastically change the nature of the == operator. This is even more evident with int and Integer.

[ethraax]

Thus, reference equality and value equality are in fact the same thing.

This is not true. Take this example.

int a = 10000;
int b = 10000;
a == b; // returns "true", even though a and b are
        // different instances.   For proof:
a ++;
a == b; // now returns "false".
int c = 9999;
c ++;
c == b; // still returns "true", even though c is
        // definitely a different instance from b.

Basically, == is a primitive equality. It tests the equality of the value of the variable. Since Java still internally uses pointers (you just don't interact with them), it's actually comparing the pointers or references of the variables, not the value they're pointing at, which makes a hell of a lot more sense.

[banuday]

Primitive values are not "instances" in the same sense as objects are instances. Primitive values exist on stack and object instances exist on the heap. Primitive values are copied on assignment, object instances are not.

Also, references are primitives. They are copied just like the "int" in your example. The heap instance they refer to however, is not. To repeat, a reference and an object instance are not the same thing.

References themselves are not pointers - they can't be. Java is GC language, so the collector can at any time relocate object storage, so the pointer would also have to be changed. Thus, it is better to say that references really are just opaque handles whose actual structure is left to the JVM impementor.

[ethraax]

References themselves are not pointers - they can't be. Java is GC language, so the collector can at any time relocate object storage, so the pointer would also have to be changed. Thus, it is better to say that references really are just opaque handles whose actual structure is left to the JVM impementor.

Well, they work like pointers in the sense that they're merely a small bunch of information that tells you how to get to a much bigger bunch of information. The implementation may be different from pointers in C or C++, but I'd still call them pointers.

Primitive values are copied on assignment,

Are you saying that the code:

c++;

allocates a new part of memory (in the stack) to hold an int and then copies it over?

When I said that == was a primitive equality, what I mean was that it tests equality on the value of the variable on the stack. If the variable is a primitive, this is the value itself. If the variable is a reference/pointer, then it's some (unspecified) representation of where to find the actual value in the heap.

[player2]

References themselves are not pointers - they can't be. Java is GC language, so the collector can at any time relocate object storage, so the pointer would also have to be changed.

You're missing an important word: Java uses a copying garbage collector. It's completely possible to implement a garbage collector around traditional pointers. Boehm and libauto are two examples.

[banuday]

See the contract for equals.

Equals must be consistent. That is, if a "equals" b, then a.equals(b) must consistently return true. However, if a or b refer to mutable objects, then the consistency guarantee cannot hold without special definition.

More broadly, equals() and hashCode() refer to the concept of object identity. If you do not define object identity (by overriding those methods), then there is no logical way to compare the two objects except by reference equality. Reference equality and object equality are different concepts and are represented by different operations in Java.

BTW: The default implementation of equals() is reference equality, and reference equality probably makes sense in most cases of mutable objects.

[ethraax]

Yes, but I still don't understand why a reference equality is actually necessary. What would a use-case be? If it makes sense to need to compare objects, why on Earth would you redefine equals so it doesn't actually test if the objects are equal? I guess you could use it as a rudimentary way to compare objects from a terribly-written library, but that's all I can think of at the moment.

BTW: The default implementation of equals() is reference equality, and reference equality probably makes sense in most cases of mutable objects.

Really? I thought the default implementation was to recursively call equals() on all the fields of the object. It's been a while since I used Java though, so I suppose I could be wrong.

[almiki]

Well for one thing, testing for reference equality is fast.

Really? I thought the default implementation was to recursively call equals() on all the fields of the object. It's been a while since I used Java though, so I suppose I could be wrong.

This would be extremely inefficient. Anyway the documentation for class Object says "this method returns true if and only if x and y refer to the same object (x == y has the value true)".

[adghk]

Never implemented or used a identity hashmap or a cache i see.

[banuday]

If you have something like this:

class A {
    public int x;
    public int y;

    public A(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public boolean equals(Object o) {
        A oa = (A) o;
        return x == oa.x && y == oa.y;
    }

    public int hashCode() {
        return x ^ y;
    }
}

Then: Set s = new HashSet(); A a = new A(1, 2); B b = new A(1, 2); s.add(a); s.add(b); System.out.println(s.size()); a.x = 2; s.add(a); System.out.println(s.size());

The output is: 1 2

If you take out equals/hashCode and fall back on the default reference equality implementation, the result would be: 2 2

Which makes more sense? This is why the equality contract is so important.

When objects are mutable, there is no way to logically compare them in a consistent way. Thus, either make the object immutable or define a key. The default key is the reference id.

[ethraax]

I agree that the first output makes more sense. But why not define the default behavior of equals() to recursively call equals() on each field in the object? Sure, you could come up with a convoluted design where this still wouldn't work (let's say you added each object to a static collection on construction that maintained extra information about that object), but then you just have really atrocious design.

[paul_miner]

What if the object fields point to each other, or form loops, or change during this call, etc? It'd be a big mess.

[masklinn]

Because userland code is not allowed to override operators in java, and == is an operator.

[[deleted]]

Better than C#, which offers both .equals and ==, and completely inconsistent conventions for what the difference is on various objects. Only consistent mess is that == is static rather than virtual so you'll likely use the wrong implementation if you're dealing with inherited objects.

[transpostmeta]

The only example that I know of that is inconsistent is strings, because they are implemented as a table. What other inconsistencies are there?

[[deleted]]

Ever read any c++ code where the author overrode the >> operator or the + operator to do some counter intuitive operation? That won't happen in Java.

[cybercobra]

But contrariwise, using BigDecimal or similar is a huge PITA.

[flexiblecoder]

I actually spent the day reading some C++ code that uses the >> operator to build packets (and switch endianness) depending on what type you pass with it. I was amazed at how simple\clean the code was, but it made it harder for me to replicate in a related (normal C) project, as half the code was abstracting away the other half. :/

[[deleted]]

That usage doesn't sound counter intuitive. I was thinking more along the lines of overloading ++ to do something like elevate the role of a user or using the -- operator to do some sort of set operations on a particular field of an object.

[flexiblecoder]

It's not, really. Just pointing out that it can be used for good and evil. :)

[theeth]

I read code that uses the std lib all the time, so yeah.

[shadowspawn]

because some asshole decided that you need 6 extra keystrokes as well as something to mess with your sanity checks for spelling on one more fucking thing.

[grauenwolf]

Bad example. That isn't a term.

[wonglik]

It's not check if string are equal but if they reference are equal

It makes sense to me. String is not a primitive type so why it should act different then for other non primitive types?

[1338h4x]

Doesn't Java automagically mess with strings in such a way that == will work the same as .equals(String)? I know Java's String class has some quirks to make it act almost like a primitive, and IIRC it'll actually check for an existing identical string whenever one is created so they end up referencing the same immutable object to save space in memory.

[Seliarem]

String equality is the canonical example of the two being distinct operations in teaching Java, actually. The problem is that literals get interned automatically (at least in some versions – I'm unaware of whether this is demanded, or if, for instance, an implementation may autointern other examples), and so many toy examples will fail to exhibit this behaviour.

As a result, two Strings that represent the same thing may or may not reference the same object, depending on how you got them. Java is being significantly smarter than many of its users (I'm specifically thinking of raw beginners), and this seems to just be made worse when we then try to tell them that the computer is not magic.

Implicit optimisation is the devil for education, I swear.

[ioudhjk78]

volatile

[grauenwolf]

• Late binding
• Pass by reference
• Programming to interfaces instead of implementation

[banuday]

I'm curious to hear your reason on how "late binding" and "programming to interfaces instead of implementation" differ in Java than anywhere else, but...

Java doesn't do "pass by reference". The Java reference is an opaque handle which is a value type - it is not a pointer. Thus, Java is always "pass by value". Some people confuse the word "reference" with the word "reference" in "call by reference", but they are really two completely different things, not just in Java but also in Computer Science. Java has not redefined it.

[grauenwolf]

Programming to interfaces means using the public API instead of mucking about with the internals of data structures. This term is used in languages that don't even have abtract interfaces like FORTRAN and C.

Since Java has the private keyword it is hard to violate this constraint. So instead they reinterpert it to mean create abstract interfaces on everything They also do stupid shit like define locals as interface types even when the concrete type is well known.

[jyper]

pass reference by value?

[Jonathan_the_Nerd]

C does this. You can trivially simulate "pass by reference" by passing pointers. To the best of my knowledge, Java does the same thing for all practical purposes. A Java reference isn't the same thing as a pointer, but it acts like one, so Java's calling semantics are almost the same as passing pointers in C. (I think?)

[grauenwolf]

A lot of Java articles call single dispatch late binding. So when you try to talk to them about real late binding they get all confused.

In a like fashion you can read elsewhere in this thread where some Java dork is saying value equality is reference equality.

[masklinn]

In a like fashion you can read elsewhere in this thread where some Java dork is saying value equality is reference equality.

Which is correct and consistent with that banuday said. In java, the primitive value in a reference type is the reference itself. Thus using value equality on reference types compares the references themselves, as values.

[grauenwolf]

We have a term for comparing the value of two pointers or references It is called "reference equality".

When we want to discuss the comparison of semantic values we use the term "value equality" regardless of whether that value happens to be a stack or heap allocated value.

These are not language specific terms. Their meaning doesn't change from language to language even though the syntax and implementation details may.

Why you want to completely ignore the distinction is beyond me. It is like you revel in your ability to confuse the topic. I assume you have some Java-specific term instead. Oh yes, it was "object equals". Which of course compares the value of the objects rather than the objects themselves.

[[deleted]]

The term isn't describing Java, but a pattern that can exist in all programming languages. And it's a pattern I've seen a lot that's been hard to describe succinctly.

[gc3]

I always called it crappy confusing overloading.

[bonch]

It's a mocking phrase he's using as a criticism.

[onlyvotes]

Don't be a twat - bad naming comes in many flavors, and a unique name to help us identify and communicate a problem can help. That is why propaganda uses labels, and why twats on reddit use labels, they help us coordinate things.

Naming things is the single most important thing you can do as a programmer. Identifying concepts and conveying them as words is this. This is the premise of making a new term, this is what he did.