On 4/27/2012 19:15, Adam Skutt wrote:
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.
With shallow copy I meant exactly that. I didn't think that my using the
term with a more general meaning would cause such a reaction.
I don't agree on the other things you said, of course.
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.
So you're saying that I said that "Primitive constructs are references".
Right...
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.
Maybe in your opinion. As I said, I don't agree with you.
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.
You misunderstood what I said. You wouldn't treat variables as if they
were values because you wouldn't even know what that means and that
that's even a possibility.
I've never heard an old C programmer talk about "value semantics" and
"reference semantics". When everything is a value, your world is pretty
simple.
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.
Will you pay me for my time?
Your problem is that you think that copy semantics requires real
copying. I really don't see any technical difficulty in virtualizing the
all thing.
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).
As always, anyone else is completely and utterly wrong, in your opinion.
Let's leave it at that.
Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list
