On Apr 27, 11:01 am, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote: > On 4/27/2012 1:57, Adam Skutt wrote: > > On Apr 26, 6:34 pm, Kiuhnm<kiuhnm03.4t.yahoo.it> wrote: > >>> If you > >> understand that your 'a' is not really an object but a reference to it, > >> everything becomes clear and you see that '==' always do the same thing. > > > Yes, object identity is implemented almost? everywhere by comparing > > the value of two pointers (references)[1]. I've already said I'm not > > really sure how else one would go about implementing it. > > >> You might tell me that that's just an implementation detail, but when an > >> implementation detail is easier to understand and makes more sense than > >> the whole abstraction which is built upon it, something is seriously wrong. > > > I'm not sure what abstraction is being built here. I think you have > > me confused for someone else, possibly Steven. > > The abstraction is this: > - There are primitives and objects. > - Primitives are not objects. The converse is also true. > - Primitives can become objects (boxing). > - Two primitives x and y are equal iff x == y. > - Two objects x and y are equal iff x.equals(y). > - Two objects are the same object iff x == y. > - If x is a primitive, then y = x is a deep copy. > - If x is an object, then y = x is a shallow copy. > - ... >
This is not an abstraction at all, but merely a poor explanation of how things work in Java. Your last statement is totally incorrect, as no copying of the object occurs whatsoever. The reference is merely reseated to refer to the new object. If you're going to chide me for ignoring the difference between the reference and the referent object, then you shouldn't ignore it either, especially in the one case where it actually matters! If we try to extend this to other languages, then it breaks down completely. > The truth: > - Primitives can be references. > - Two primitives are equal iff x == y. > - Operator '.' automatically derefences references. > You have the first statement backwards. References are a primitive construct, not the other way around. While true, it's still a bad way to think about what's going on. It breaks down once we add C++ / Pascal reference types to the mix, for example. It's better to think about variables (names) and just recognize that not all variables have the same semantics. It avoids details that are irrelevant to writing actual programs and remains consistent. > Equality or equivalence is a relation which is: > - reflexive > - symmetric > - transitive > Everything else... is something else. Call it semi-equality, > tricky-equality or whatever, but not equality, please. Sure, but then it's illegal to allow the usage of '==' with floating point numbers, which will never have these properties in any usable implementation[1]. So we're back to what started this tangent, and we end up needing 'equals()' methods on our classes to distinguish between the different forms of equality. That's precisely what you want to avoid. Or we can just accept that '==' doesn't always possess those properties, which is what essentially every programming language does, and call it (value) equality. As long as we don't cross incompatible meanings, it's hard to believe that this isn't the right thing to do. > > > If anything, you have that backwards. Look at Python: all variables > > in Python have pointer semantics, not value semantics. > > When everything is "white", the word "white" becomes redundant. > So the fact that everything in Python have reference semantics means > that we can't stop thinking about value and reference semantics. Nope. The behavior of variables is absolutely essential to writing correct programs. If I write a program in Python that treats variables as if they were values, it will be incorrect. > > > In imperative > > languages, pointers have greater utility over value types because not > > all types can obey the rules for value types. For example, I don't > > know how to give value semantics to something like a I/O object (e.g, > > file, C++ fstream, C FILE), since I don't know how to create > > independent copies. > > By defining a copy constructor. Then write me a working one. I'll wait. To save yourself some time, you can start with std::fstream. > Python is already without pointers (*). > A world where everyone is a lawyer is a world without lawyers (really, > there isn't any other way we can get rid of them :) ). > > (*) By the way, some would argue that references are not pointers. They would be completely and utterly wrong, and probably imbuing pointers with properties they don't actually possess. Unless you're talking about C++ / Pascal references, which really aren't pointers and do possess a different set of semantics (alias might be a better term for them). Adam [1] Not in any fashion that's useful to the programmer, at any rate. -- http://mail.python.org/mailman/listinfo/python-list
