"Pavel Minayev" <evilone@omen.ru> wrote in message news:a6j5cq$1kvr$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a6j4im$1kgt$1@digitaldaemon.com...
>
> > So how about a way to say "use value semantics" or "use reference semantics"?
> >
> > Maybe this:
> >
> > if (&dtA == &dtB)  // Compare references
> > if (*dtA == *dtB)    // Compare values
> >
> > Comments, suggestions, negatives?
>
> First of all, where's (dtA == dtB)?

I guess it would be the same as &==.


>
> Then, &foo is a pointer to foo. So:
>
>     char[] foo;
>     char[]* bar = &foo;
>
> I guess that, for objects, you'd prefer reference semantics
> (you can always use .cmp() to check for equality). For arrays,
> however, value semantics seems to be preferrable.
>

What about dates? And int256?
Operator overloading implies value semantics, at least in
my mind.

And, I am afraid to say that I don't like cmp(), because
a lot of classes support operators != and ==, but not
operators >, < and <= and >=....
Do you see the problem? If cmp() returns 1, does that
mean that object b is larger than object a, or just that
it is not equal to it. This is an ambiguity that I do not
like. Apart from that, this basically is the same problem
as plagued C for many years, where an int was used to
simulate a bool. If one programmer returns -1 when two
objects are unequal, while another programmer returns
1, you have the old C problem of false != false,
or unequal != unequal in this case. If operator overloading
is out, then please define Equal(), Larger() and Smaller()
functions that return bool's....


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

OddesE wrote:
> And, I am afraid to say that I don't like cmp(), because
> a lot of classes support operators != and ==, but not
> operators >, < and <= and >=....
> Do you see the problem? If cmp() returns 1, does that
> mean that object b is larger than object a, or just that
> it is not equal to it. 

In my little world, it means that object b is to be
presented after object a in an ascending sort, and
nothing else. Even if it's hard to say what's "greater"
or "lesser", it's often valuable to have a consistent
sorting order[1].

-Russell B

[1] Consider something like nethack, a game where your
character has several kinds of things in inventory:
food, rings, weapons, armor, potions -- it's nice to
have all the food sort together, but silly to say
that "food is value-larger than potions".

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C8D1F5C.7010108@estarcion.com...
> OddesE wrote:
> > And, I am afraid to say that I don't like cmp(), because
> > a lot of classes support operators != and ==, but not
> > operators >, < and <= and >=....
> > Do you see the problem? If cmp() returns 1, does that
> > mean that object b is larger than object a, or just that
> > it is not equal to it.
>
> In my little world, it means that object b is to be
> presented after object a in an ascending sort, and
> nothing else. Even if it's hard to say what's "greater"
> or "lesser", it's often valuable to have a consistent
> sorting order[1].
>
> -Russell B
>
> [1] Consider something like nethack, a game where your
> character has several kinds of things in inventory:
> food, rings, weapons, armor, potions -- it's nice to
> have all the food sort together, but silly to say
> that "food is value-larger than potions".
>


It still doesn't adress the unequal != unequal problem.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a6j66b$1l7n$1@digitaldaemon.com...

> What about dates? And int256?

If these are classes, == should check for equality of references. If they are structs, then it's overloadable.

> And, I am afraid to say that I don't like cmp(), because
> a lot of classes support operators != and ==, but not
> operators >, < and <= and >=....
> Do you see the problem? If cmp() returns 1, does that
> mean that object b is larger than object a, or just that
> it is not equal to it. This is an ambiguity that I do not
> like. Apart from that, this basically is the same problem
> as plagued C for many years, where an int was used to
> simulate a bool. If one programmer returns -1 when two
> objects are unequal, while another programmer returns
> 1, you have the old C problem of false != false,
> or unequal != unequal in this case. If operator overloading
> is out, then please define Equal(), Larger() and Smaller()
> functions that return bool's....

Then, an equal() function could be added:

    class Object
    {
        bit equal(Object other) { return false; }
    }

Pavel Minayev wrote:

> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a6j66b$1l7n$1@digitaldaemon.com...
>
> > What about dates? And int256?
>
> If these are classes, == should check for equality of references. If they are structs, then it's overloadable.

> Then, an equal() function could be added:
>
>     class Object
>     {
>         bit equal(Object other) { return false; }
>     }

ICK!  This is one of the worst artifacts of Java!  I think that ==
should compare value, and you can have a function (like
compareReference() or something) to compare address.

Generally, it's not the reference that's important (particularly in a garbage collected language) - it's the internal value!

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> schrieb im Newsbeitrag news:3C8E10BA.8CFEAD52@deming-os.org...
> Pavel Minayev wrote:
>
> > "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a6j66b$1l7n$1@digitaldaemon.com...
> >
> > > What about dates? And int256?
> >
> > If these are classes, == should check for equality of references. If they are structs, then it's overloadable.
>
> > Then, an equal() function could be added:
> >
> >     class Object
> >     {
> >         bit equal(Object other) { return false; }
> >     }
>
> ICK!  This is one of the worst artifacts of Java!  I think that ==
> should compare value, and you can have a function (like
> compareReference() or something) to compare address.
>
> Generally, it's not the reference that's important (particularly in a garbage collected language) - it's the internal value!

ACK! And even more acks, since I believe that Java only compare by reference by default, because in Java you cannot write:

if (&a == &b)

But in D you can, so comparing by reference is just simple! Providing comparing by value the default statement is much better, IMHO.

Arrays should not be simple pointers to their first element, and so char[] == char[] sould not compare pointers to the f.el.

Imi

"Immanuel Scholz" <digitals-mars@kutzsche.net> wrote in message news:a6l6sv$ncm$1@digitaldaemon.com...
>
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> schrieb im Newsbeitrag news:3C8E10BA.8CFEAD52@deming-os.org...
> > Pavel Minayev wrote:
> >
> > > "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a6j66b$1l7n$1@digitaldaemon.com...
> > >
> > > > What about dates? And int256?
> > >
> > > If these are classes, == should check for equality of references. If they are structs, then it's overloadable.
> >
> > > Then, an equal() function could be added:
> > >
> > >     class Object
> > >     {
> > >         bit equal(Object other) { return false; }
> > >     }
> >
> > ICK!  This is one of the worst artifacts of Java!  I think that ==
> > should compare value, and you can have a function (like
> > compareReference() or something) to compare address.
> >
> > Generally, it's not the reference that's important (particularly in a garbage collected language) - it's the internal value!
>
> ACK! And even more acks, since I believe that Java only compare by reference by default, because in Java you cannot write:
>
> if (&a == &b)
>
> But in D you can, so comparing by reference is just simple! Providing comparing by value the default statement is much better, IMHO.
>
> Arrays should not be simple pointers to their first element, and so char[] == char[] sould not compare pointers to the f.el.
>
> Imi
>

I definitely agree with you that you normally compare by value
by default, however, what about assign? Now assigning one
reference to another *is* quitte common. More common in
fact than assigning by value (I think?). So now what?
Making compares act on values by default and assigns on
references is just sooo inconsistent, the thought alone makes
me shiver. Now here is my reasoning:

1) You always have to assign references to one and another
     in a typical program.
2) You often have to copy objects by value, but it is used
     less frequently (notice how you don't need Java's Clone()
     all that much compared to normal assignment with = )
3) You often have to compare objects by value, but this
     is also used less frequently as assign by reference.
4) You sometimes need to compare by reference, but this
     is quitte rare.

Comparison can be done by value as well as by reference just as with assignment but comparison by value makes more sense than comparison by reference as the default case.

Now it seems to me that, even though comparison by value
is the more typical situation, you can't make it the default
because assignment by reference is more typical than assignment
by value and you need assignment far more than you need
comparison.

Notice though, how this applies to all math operators. Addition, subtraction or multiplication by reference anyone?

So we have a problem. The problem is that assignment is used very frequently and should be by reference. However, the other operators, though used much less frequently, should all be by value.

I see two solutions for this problem:

A) Introduce syntax to make the distinction between reference
     and value semantics.
B) Introduce a new assign-by-value operator.

Solution A is more flexible, but will lead to problems, because reference semantics *have* to be the default because reference assignment is used so much.

Solution B might, in fact be quitte clean. Consider this:

// Assume class Foo has operators := and == overloaded.

Foo a, b, c;             // Define a, b and c
a = new Foo (12);   // Set a to 12
b = a;                      // Copy a by ref. into b
c := a;                      // Copy a by value into c
if (a == b)                // true
if (a == c)                // true
b := 15;                   // assign 15 to b by value
if (a == b)                // a and b refer to same object, so true
if (a == c)                // c is another object holding 12, so false

Best would be, in my opinion to combine both approaches,
making a syntax to say "by reference" (probably the reference
operator, &) but introducing a new assign by value operator :=
and making all operators work by value as the default except
for the assign-by-reference operator =. This way you can
implement operator overloading in a consistant and intuitive
way, without creating ambiguities about wheter assignment
is by value or by reference and without breaking existing
code.
Now I already hear you say that having two assignment
operators is bad, but why? It is a very special operator
anyhow, since it does not exist is math (to my knowledge)
and there is a real consistency gain if it were to be used.

Well, this post is already getting way too long, so I'll shut up and wait for your suggestions, comments and negatives  :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

OddesE wrote:

> I definitely agree with you that you normally compare by value
> by default, however, what about assign? Now assigning one
> reference to another *is* quitte common. More common in
> fact than assigning by value (I think?). So now what?
> Making compares act on values by default and assigns on
> references is just sooo inconsistent, the thought alone makes
> me shiver. Now here is my reasoning:

Ouch.  Good point.

I think, however, that we have already solved it (of sorts) with arrays:

    a = b;    // assign by reference
    a[] = b;    // assign by value

Maybe we could use the dereferencing operator (  *  ) analagously:

    Object a,b;
    a = b;    // assign by reference
    *a = b;    // assign by value

Earlier, somebody (myself or somebody else, I forget who) suggested using the array syntax for comparisons; the same could work for references:

    int[] a,b;
    Object c,d;
    if(a == b)    // compare by reference
    if(a[] == b)    // compare by value
    if(c == d)    // compare by reference
    if(*c == d)    // compare by value

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

OddesE wrote:
> "Russell Borogove" <kaleja@estarcion.com> wrote in message
> news:3C8D1F5C.7010108@estarcion.com...
> 
>>OddesE wrote:
>>
>>>And, I am afraid to say that I don't like cmp(), because
>>>a lot of classes support operators != and ==, but not
>>>operators >, < and <= and >=....
>>>Do you see the problem? If cmp() returns 1, does that
>>>mean that object b is larger than object a, or just that
>>>it is not equal to it.
>>>
>>In my little world, it means that object b is to be
>>presented after object a in an ascending sort, and
>>nothing else. Even if it's hard to say what's "greater"
>>or "lesser", it's often valuable to have a consistent
>>sorting order[1].
>
> 
> It still doesn't adress the unequal != unequal problem.

Well, again, since cmp() doesn't return a bool (in fact,
it needn't be restricted to -1, 0, or 1 - you can simply
return (b-a) for valued types), it's hazardous to use
its return value as if it were boolean. In my little
world, of course, I have operator overloading, so I can
make boolean != and == operators that do the right thing.

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C8E3F00.4070800@estarcion.com...
> OddesE wrote:
> > "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C8D1F5C.7010108@estarcion.com...
> >
> >>OddesE wrote:
> >>
> >>>And, I am afraid to say that I don't like cmp(), because
> >>>a lot of classes support operators != and ==, but not
> >>>operators >, < and <= and >=....
> >>>Do you see the problem? If cmp() returns 1, does that
> >>>mean that object b is larger than object a, or just that
> >>>it is not equal to it.
> >>>
> >>In my little world, it means that object b is to be
> >>presented after object a in an ascending sort, and
> >>nothing else. Even if it's hard to say what's "greater"
> >>or "lesser", it's often valuable to have a consistent
> >>sorting order[1].
> >
> >
> > It still doesn't adress the unequal != unequal problem.
>
> Well, again, since cmp() doesn't return a bool (in fact,
> it needn't be restricted to -1, 0, or 1 - you can simply
> return (b-a) for valued types), it's hazardous to use
> its return value as if it were boolean. In my little
> world, of course, I have operator overloading, so I can
> make boolean != and == operators that do the right thing.
>
> -RB
>

Indeed you are right  :)
But since we do not have operator overloading in D,
I was trying to point out it's need by showing why
cmp() is not a viable alternative for comparing two
values, especially if you want to compare for unequality.
(Ofcourse, you could always write:

if ((cmp (a,b) != 0) && (cmp (c,d) != 0))

to compare for unequality, but it just, well...,
sucks basically  :)  )


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail