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

[Kiuhnm]

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