why () is () and [] is [] work in other way?

[Adam Skutt]

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.