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

[Kiuhnm]

On 4/28/2012 16:18, Adam Skutt wrote:
> On Apr 28, 7:26 am, Kiuhnm<kiuhnm03.4t.yahoo.it>  wrote:
>> On 4/27/2012 19:15, Adam Skutt wrote:
>>> On Apr 27, 11:01 am, Kiuhnm<kiuhnm03.4t.yahoo.it>    wrote:
>>>> 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.
>
> It has a very strict, well-defined meaning in these contexts,
> especially in languages such as C++.

In C++ it's called "memberwise copy" (see the C++ spec), which is not 
equivalent to Java's "shallow copy", thanks to copy constructors.

>> So you're saying that I said that "Primitive constructs are references".
>> Right...
>
> No, still wrong.

You said:
"You have the first statement backwards.  References are a primitive
construct, not the other way around."
The other way around is "Primitive construct are references", but I 
never said that.

>  What I said is correct, "References are a form of
> primitive construct".  In C, an int is a primitive but not a
> reference.  An int* is a pointer (reference), and is also
> (essentially) a primitive.

I never said it isn't.

>>>   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.
>>
>> ?
>
> Assignment to a C++ reference (T&) effects the underlying object, not
> the reference itself.  A reference can never be reseated once it is
> bound to an object.  Comparing equality on two references directly is
> the same as comparing two values (it calls operator==).  Comparing
> identity requires doing (&x ==&y), like one would do with a value.
> However, unlike a value, the object is not destroyed when the
> reference goes out of scope.  Most importantly, references to base
> classes do not slice derived class objects, so virtual calls work
> correctly through references.
>
> As a result, normally the right way to think about a value is as a
> "temporary name" for an object and not worry about any of the details
> about how the language makes it work.

If you add C++ references to Java, the abstraction breaks down too, so I 
don't see your point.

>>>> 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].
>>
>> ???
>>
>
> The operator == is called the equality operator.  Floating-point
> numbers don't really obey those properties in any meaningful fashion.

I say they do. Any counter-examples?

> The result is that portions of your view contradict others.  Either we
> must give '==' a different name, meaning what you consider equality is
> irrelevant, or we must use method names like 'equals', which you find
> objectionable.
>
>>>>> 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.
>
> Well, one hopes that is true.  I think we have a misunderstanding over
> language: you said "value and reference semantics" when you really
> meant "value vs. reference semantics".

Ok.

>> 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.
>
> Except if that were true, the comp.lang.c FAQ wouldn't have this
> question and answer: http://c-faq.com/ptrs/passbyref.html, and several
> others.

That's why I said "an /old/ C programmer".

> Much as you may not like it, most code doesn't care about a pointer's
> value, doesn't need to know anything about it, and would just as soon
> pretend that it doesn't exist.  All it really wants is a controlled
> way to mutate objects in different scopes.  Which is precisely why
> references are preferred over pointers in C++, as they're a better
> expression of programmer intent, and far safe as a result.
>
> Peaking under the covers in an attempt to simplify the definition of
> '==' is silly.  As I've hopefully shown by now, it's pretty much a
> fool's errand anyway.

You say a lot of true things as I already said, but they don't prove 
anything. You say "this is bad or right because <something true>". That 
"because" is what we don't agree on.

As I already said, if the abstraction is (much) more complex than the 
mechanism under the hood, in my opinion, the abstraction is bad.

>>>>>    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?
>
> No, because you'll never finish.  There's a reason why std::fstream
> lacks one, and it isn't because the committee is lazy.
>
>>
>> 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.
>
> Then you would have written one already.

What a solid reasoning.

>  They do require real
> copying, though.

Think what you want.

Kiuhnm