Re: What ops to use for operator overloading for cross and dot products.

OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3pf92$4ul$1@digitaldaemon.com...
> The one you use most. The other you use a named function for. Without operator overloading you will always have to use a named function to describe mathematical operations.

Translation....  Operator overloading as provided by C++ is inadequate for even simple vector operations, which was it's primary reason for existance.

I rest my case.  Operator overloading is essentially useless.

Allowing the programmer to define their own operators on the other hand is a valuable addition to a language.

"Serge K" <skarebo@programmer.net> ha scritto nel messaggio news:a3ql6l$21ts$1@digitaldaemon.com...
> > I wouild make one exception. Equality.  Equality can at all times be
taken
> > to be byte by byte identical. for comparison, and byte by byte
assignment
> > for assignment.
>
> According to IEEE 754,
> -0.0 == +0.0, but have different binary representation.
>

Ant it's not the only example.

CaseInsensitiveString s = "CIAO", t = "ciao";

if (s == t)
  ...

Really?  I didn't know that.

Don't follow IEEE 754 specifiations as it is an ill conceived and irrational standard.

If the language is to have ouitput structures, I would seem appropariate that in the assignment phase from a standard struct that the conversion of -0 to +0 be made.

Serge K <skarebo@programmer.net> wrote in message news:a3ql6l$21ts$1@digitaldaemon.com...
> > I wouild make one exception. Equality.  Equality can at all times be
taken
> > to be byte by byte identical. for comparison, and byte by byte
assignment
> > for assignment.
>
> According to IEEE 754,
> -0.0 == +0.0, but have different binary representation.

OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3ph43$61j$1@digitaldaemon.com...
> Consider this pieces of code:
>
> define op var1 ** var3 = MyClass::Multiply(Var1,Var3)
> define op var1. *+ var3 = MyClass::Add(Var1.Var3)
> define op var1 #* var3 = MyClass::Multiply(Var1,Var3)
> define op var1. #+ var3 = MyClass::Add(Var1.Var3)
> define op var1 $* var3 = MyClass::Multiply(Var1,Var3)
> define op var1. $+ var3 = MyClass::Add(Var1.Var3)
> define op var1 @* var3 = MyClass::Multiply(Var1,Var3)
> define op var1. @+ var3 = MyClass::Add(Var1.Var3)
> define op var1 &* var3 = MyClass::Multiply(Var1,Var3)
> define op var1. &+ var3 = MyClass::Add(Var1.Var3)
>
> MyClass::result =  Var1 *+ Var1 ** Var3
> MyClass::result =  Var1 #+ Var1 #* Var3
> MyClass::result =  Var1 $+ Var1 $* Var3
> MyClass::result =  Var1 @+ Var1 @* Var3
> MyClass::result =  Var1 &+ Var1 &* Var3

Yup I do see difficulty with your code.   It's difficult to read because you
have
chosen to define the same function for multiply and add a total of 5 times.

Very poor programming practice.

Consider the equivalent defined only once....
define op var1 ** var3 = MyClass::Multiply(Var1,Var3)
define op var1. *+ var3 = MyClass::Add(Var1.Var3)

MyClass::result =  Var1 *+ Var1 ** Var3


Reasonably readable but flawed.  I find it odd that you would see the need
to create a new operator by combining
two thers.  Still purposely trying to write obfuscated code I guess.

Here is a superior alternative.

define op var1 :* var3 = MyClass::Multiply(Var1,Var3)
define op var1. :+ var3 = MyClass::Add(Var1.Var3)

MyClass::result =  Var1 :+ Var1 :* Var3

Yes, quite readable now that the purposeful obfuscation has been removed.



Odesse writes:
> How am I supposed to know what strange character
> sequence a programmer selected to convey a plus operation?

   One presumes that programmers will take care in selecting meaninful
names for their operators just as they are preseumed to select meaninful
names
for their functions.

  Also, since operator overloading is abolished, there is a 1:1 mapping of
operators to function (with the exception of equality).  So all we need do
is keep
a our list of operators handy and we can understand any function presented
to us.

  It's as simple as that.


Odesse writes:
> You could use some kind of standard, but what is the
> point?

No standards are needed.   :V+ is a nice enough name for vector add.
If vector operators are the only things added the programmer might select :+
Matrix multiplication might could be indicated by :M* or :MtxMul, or
whatever
name the programmer sees fit to use.


Odesse writes::
> Why do you think people can easily abuse normal
> operator overloading, but replacing the normal operator
> sign that everyone knows with some weird sign nobody
> knows wil leviate this problem?

  Primarily because as you yoursef showed in another thread,
they aer forced to by the limited number of existing operators.


Odesse writes:
> Who keeps me from doing this:
>
> define op var1 .* var3 = MyClass::Add (Var1,Var3)
> define op var1. .+ var3 = MyClass::Multiply (Var1.Var3)
>
> MyClass::result =  Var1 .+ Var1 .* Var3

Absolutely nothing.  Do you regularly program in that manner?

Do you label your functions with names like "aelfkie" and "xxxxxxx"?

Chosing appropriat labels is one aspect of proper programming.


Odesse writes:
> I really don't see any big differences in this.
> Your solution does not prevent the abuse you keep talking
> about.

There are 4 differences.

1. Existing operators do not change their meaning and therefore
    all lines containing existing operators can be taken at face value
    rather than being suspect of hiding some unsuspected behaviour.

2. There is a 1:1 relationship between operator and function which enables
    the programmer to use a simple operator table to figure out what a
specific
    equation means

3. I recommend that all new operators have the same precedence. Hence there
    is no confusion in the order of operations, and no unnatural
consequences to
   what would otherwise be automatic reordering.

4. New operators would provide visual cues that readily distinguish them
from
    existing operators, thereby allowing the programmer to readily identify
new program
    behaviour.




Odesse writes:
> Ok, so maybe if people see .= they will look it up
> in the docs. Or maybe they just assume it is assign. At least
> with the normal = there is a defined meaning what the
> operator *should* do. Now it could be anything. I think the
> code just got much _less_ self-documenting!

Now they could presume it is an assignment, but the colon at the front of the operator indicates new behaviour that distinguishes it from simple assignment.

You may elect to ignore visual cues like that, but I would not.

On the other hand with overloading you wouldn't see

:=   (colon equal)

you would see

=  (equal)

Which is identical to

=  (equal)

Yet the first equal under your regime of operator overloading would have a
meaning that is entirely
different than the second equal symbol,.

Your system, no visual cues.

Your system is inferior.





> > OdessE writes:
> > > Now I doubt that there will be many people telling me the first snippet is more readable than the second.
> >
> > Now I dount that there will be many people telling me that
> >
> > MyClass::result =  Var1 .+ Var1 .* Var3
> >
> > is any less readable than
> >
> > MyClass result = Var1 + Var1 * Var3;
> >

Odesse writes:
> I am telling it. I never saw an operator .+ before. Not in
> Delphi/Java/C/C++, nor in math. How am I supposed to
> know what it means?

You go to the top of the module, find the definition and read it. Alternately you pull out your quick reference chart and read it. Alternately you rememher what it means and continue with the interpretation.

I fail to see your difficulty.



Odesse writes:
>  I could *assume* it means plus,
> but I wouldn't know it. At least with normal + I know
> what it normally means (in math or other languages).

You can assume many things.  The colon in front of the label is a visual cue that you may not assume anythign.

Assume at your own peril.


> > OdessE writes:
> > > After I wrote
> > > it, I had to examine it 4 times to make sure I had it correct,
> > > with all the braces and the order of the arguments.
> >
> > I had no such burden.
> >
>
> Good for you, but you are contradicting yourself with this
> cowboy-coder comment. So if you know what it means
> than it is not a problem eh?

  Nope, it's not a problem because you can easily remember what it means
as well.  Most importantly the colon at the front of the label is your cue
that unusual behaviour is taking place.



Odesse writes:
> You still didn't say that
>
> MyClass result.Assign(MyClass::.Add (Var1, MyClass::Multiply (Var1,
Var3)));
>
> is more readable than
>
> MyClass result = Var1 + Var1 * Var3;
>
> probably because it just isn't.

Yes, the first statement is more readable than the second because
in the case of the second statement we are not told what + and * do.
We only know that they perform some unknown operation, and that operation
depends on the variable types which are not specified.

Hence we can say nothing about the second function.


However in the case of :+ and :* there is a 1:1 correspondance between function and operator label so knowing that

:* = Myclass::Multiply(Var1,Var3)
:+ = Myclass::Add(Var1,Var3)

We know everything we need to know about the equation.

It's really quite simple.  I fail to see your objection.



> > > > The problem with operator overloading is that it can be highly
> > confusing.
> > > > What Isn't highly confusing however, and what does provide the same
> > > benefit
> > > > is providing the ability to create your own operators.
> >
> > OdessE writes:
> > > Mmmm.... So you don't understand what A + B or C * D
> > > means, but you do understand all of the very complex
> > > operators that exist in math today, as well as the ones that
> > > I personally come up with?
> >
> > Clearly no one can, since the meaning of + and * are dependent on the
> types
> > of A, B, C and D.

Odesse writes:
> And clearly no one can now the meaning of .+ and .*

Since there is a 1:1 correspondance of  label and funtion, you consult your opcode table.

You can not do this with + and * since there are no visual clues that + and
* are
doing anything outside their ordinary meaning.

a = b + c
d = e + f

In your inferior system of operator overloading the first example above may
be
doing a simple addition,. while the second could be adding a graphic to a
web page an
uploading the result to a server.

Quite foolish.

Odesse writes:
> At least with normal operators I know what they usually do and have a reference in math or other languages to draw experience on.

   And you can still use that by creating new operators with names similar
to the existing operators.  :+ in place of + for example.

  But you have the advantage of creating new operators with more
appropriate labels as well

  For example :dot or :cross for dot and cross products  If the colon were
more visible
on this screen I would have used colon period, for dot product and colon x
for cross product.

  So all of the advantages of operator overloading exist while all of the
failures of C++ style operator
overloading can be avoided.

  Operator overloading is clearly inferior.
.

> > It depends on what A and B are.and what you are trying to do.  Perhaps A
> and
> > B are objects, the == syntax can have three equally appropriate
meanigns.
> A
> > is numerically identical to B,  A is functionally identical to B, A and
B
> > are the same object.
> >
> > With one equal sign, how do you intend to distingish between these three poetntial meanings?  How do you intend to implement more than one of
them
> at
> > a time?
> >
> > I await your response.

Odesse writes:
> I don't really see how Cmp solves these issues better then operator
> overloading.
> And if you compare two numbers to see if they are equal, do you try to
find
> out if the are the same instance of an int? Draw from experience.

That may very well be a requirement yes.  That int may very well be a
semiphore used
for synchronization, or used by the program to tell if it is looking at an
instance of itself.

Once again I fail to see your complaint.



Odesse writes:
> int A = 10;
> int B = 10;
> int C = 0;
>
> if (A == B)
>    C = A;
> B = 5;
>
> What value does C have?

If this langauge allows all operators to be overloaded even for the base
types
then we do not know the answer because somewhere elsewhere in the program
the operators may have hand their meaning altered.


Odesse, your argument has been obliterated by common sense.

At this point you are simply embarrasing yourself.

I recommend you stop before damaging your reputation further.

"D" <s_nudds@hotmail.com> wrote in message news:a3qts2$26e1$1@digitaldaemon.com...
> Really?  I didn't know that.
>
> Don't follow IEEE 754 specifiations as it is an ill conceived and
irrational
> standard.

Yeah, and then you can throw your FPU away and forget about it...

"D" <s_nudds@hotmail.com> wrote in message news:a3qtmm$2694$1@digitaldaemon.com...

> I rest my case.  Operator overloading is essentially useless.
>
> Allowing the programmer to define their own operators on the other hand is
a
> valuable addition to a language.

You are the only one in the group who has such an opinion. All others either don't use operator overloading at all, or want to be able to overload standard operators. Seems like you're outnumbered here, and since we have representatives from many areas of IT here, I guess it's an answer to a logical question, "What do you prefer", apllied to the entire target audience of D. Your arguments are not conceiving - noone had changed his mind. I believe the discussion is closed here. I'm out, at least. Period.

Paul, left to themselves members of the C religion would change nothing,
because they are sheep
who generally don't know any better.

There are a plethora of langauges that resemble C, and each have been
created to appeal to the
irrational and inferior dictates of the C religionists.

If the author of D wishes to make the same mistakes as all of the others,
and as a result have
his langauge relegated to the same disgarded heap, that is his choice.

I don't recommend following in the footsteps of abject failure. Why do you?

Pavel Minayev <evilone@omen.ru> wrote in message news:a3r4l9$2993$1@digitaldaemon.com...
> You are the only one in the group who has such an opinion. All others either don't use operator overloading at all, or want to be able to overload standard operators. Seems like you're outnumbered here, and since we have representatives from many areas of IT here, I guess it's an answer to a logical question, "What do you prefer", apllied to the entire target audience of D. Your arguments are not conceiving - noone had changed his mind. I believe the discussion is closed here. I'm out, at least. Period.

Why is that Paul.  Are you unable to change -0.0 into 0.0?

I thought you were a programmer.
Am I mistaken?

Pavel Minayev <evilone@omen.ru> wrote in message news:a3r4g9$298b$2@digitaldaemon.com...
> "D" <s_nudds@hotmail.com> wrote in message news:a3qts2$26e1$1@digitaldaemon.com...
> > Really?  I didn't know that.
> >
> > Don't follow IEEE 754 specifiations as it is an ill conceived and
> irrational
> > standard.
>
> Yeah, and then you can throw your FPU away and forget about it...

What the hell is a case insensitive string.  Now that is a dum idea.  Case insensitive comparison.  That is a smart idea.

In any case, If there was such a thing as a case insensitive string, then make an exception.

I fail to see the difficulty.

By the way Roberto. if a case insensitive string is printed, is it printed in upper or lower case?

Also Robert, you can create a case insensitive string simply by changing the case to all upper or all lower during the load.  Since the case is insensitive, altering the case during the load is not relevant is it?


Roberto Mariottini <rmariottini@lycosmail.com> wrote in message news:a3qtn7$2697$1@digitaldaemon.com...
>
> "Serge K" <skarebo@programmer.net> ha scritto nel messaggio news:a3ql6l$21ts$1@digitaldaemon.com...
> > > I wouild make one exception. Equality.  Equality can at all times be
> taken
> > > to be byte by byte identical. for comparison, and byte by byte
> assignment
> > > for assignment.
> >
> > According to IEEE 754,
> > -0.0 == +0.0, but have different binary representation.
> >
>
> Ant it's not the only example.
>
> CaseInsensitiveString s = "CIAO", t = "ciao";
>
> if (s == t)
>   ...
>
>

"D" <s_nudds@hotmail.com> wrote in message news:a3r33g$28jj$1@digitaldaemon.com...
>
> OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3ph43$61j$1@digitaldaemon.com...
> > Consider this pieces of code:
> >
> > define op var1 ** var3 = MyClass::Multiply(Var1,Var3)
> > define op var1. *+ var3 = MyClass::Add(Var1.Var3)
> > define op var1 #* var3 = MyClass::Multiply(Var1,Var3)
> > define op var1. #+ var3 = MyClass::Add(Var1.Var3)
> > define op var1 $* var3 = MyClass::Multiply(Var1,Var3)
> > define op var1. $+ var3 = MyClass::Add(Var1.Var3)
> > define op var1 @* var3 = MyClass::Multiply(Var1,Var3)
> > define op var1. @+ var3 = MyClass::Add(Var1.Var3)
> > define op var1 &* var3 = MyClass::Multiply(Var1,Var3)
> > define op var1. &+ var3 = MyClass::Add(Var1.Var3)
> >
> > MyClass::result =  Var1 *+ Var1 ** Var3
> > MyClass::result =  Var1 #+ Var1 #* Var3
> > MyClass::result =  Var1 $+ Var1 $* Var3
> > MyClass::result =  Var1 @+ Var1 @* Var3
> > MyClass::result =  Var1 &+ Var1 &* Var3
>
> Yup I do see difficulty with your code.   It's difficult to read because
you
> have
> chosen to define the same function for multiply and add a total of 5
times.
>

I actually did not do that. 5 other programmers did that. Some of them
were on other teams, others were with other companies that we use
libraries of. All these declarations were in different files and were part
of different libraries. Unfortunately they all do the same thing, they all
add two strings. All these programmers noticed the lack of string support
in language X but, since it did include adding new operators, they
invented one of their own. Unfortunately I have to memorize them all,
or find different libraries.


> Very poor programming practice.
> Consider the equivalent defined only once....
> define op var1 ** var3 = MyClass::Multiply(Var1,Var3)
> define op var1. *+ var3 = MyClass::Add(Var1.Var3)
>

You try to convince hundreds of programmers to use your style...
Math already has defined these operators, but no, you can't
use those...Invent some of your own...

> MyClass::result =  Var1 *+ Var1 ** Var3
>
>
> Reasonably readable but flawed.  I find it odd that you would see the need
> to create a new operator by combining
> two thers.  Still purposely trying to write obfuscated code I guess.

No I just had no clue, like all programmers according to you.


>
> Here is a superior alternative.
>
> define op var1 :* var3 = MyClass::Multiply(Var1,Var3)
> define op var1. :+ var3 = MyClass::Add(Var1.Var3)
>
> MyClass::result =  Var1 :+ Var1 :* Var3
>
> Yes, quite readable now that the purposeful obfuscation has been removed.
>

What does the : mean?
Where is the standard? What prevents other companies from using
entirely different standards? How am I supposed to remember all
this? I am not as good as you at memorizing tables with useless data...

>
>
> Odesse writes:
> > How am I supposed to know what strange character
> > sequence a programmer selected to convey a plus operation?
>
>    One presumes that programmers will take care in selecting meaninful
> names for their operators just as they are preseumed to select meaninful
> names
> for their functions.
>
>   Also, since operator overloading is abolished, there is a 1:1 mapping of
> operators to function (with the exception of equality).  So all we need do
> is keep
> a our list of operators handy and we can understand any function presented
> to us.
>
>   It's as simple as that.
>

Great, all these lists and tables. Let's name our variables var1, var2 and
var3,
then keep a list of what they mean.


>
> Odesse writes:
> > You could use some kind of standard, but what is the
> > point?
>
> No standards are needed.   :V+ is a nice enough name for vector add.

Your opinion. I don't agree. I still don't mean what the colon stands for. I could guess at the V, but I don't like guessing what code does, I like knowing so from experience and common sense.


> If vector operators are the only things added the programmer might select
:+

Ditch the colon, of which I don't understand the meaning, and what is left?


> Matrix multiplication might could be indicated by :M* or :MtxMul, or
> whatever
> name the programmer sees fit to use.

Ah yes, :MtxMul...
Starts to sound a lot like a regular function name doesn't it?
What is the point?


>
>
> Odesse writes::
> > Why do you think people can easily abuse normal
> > operator overloading, but replacing the normal operator
> > sign that everyone knows with some weird sign nobody
> > knows wil leviate this problem?
>
>   Primarily because as you yoursef showed in another thread,
> they aer forced to by the limited number of existing operators.
>

Yes, but why replace the existing ones with substitutes that
do exactly the same, such as :V+ ?
Adding a sqrt operator is a different matter altogether, there
doesn't exist one in the programming language at the moment.


>
> Odesse writes:
> > Who keeps me from doing this:
> >
> > define op var1 .* var3 = MyClass::Add (Var1,Var3)
> > define op var1. .+ var3 = MyClass::Multiply (Var1.Var3)
> >
> > MyClass::result =  Var1 .+ Var1 .* Var3
>
> Absolutely nothing.  Do you regularly program in that manner?

I don't, but you keep saying that programmers are clueless and do such things. I am asking you how your method prevents this.


>
> Do you label your functions with names like "aelfkie" and "xxxxxxx"?
>
> Chosing appropriat labels is one aspect of proper programming.
>
>
> Odesse writes:
> > I really don't see any big differences in this.
> > Your solution does not prevent the abuse you keep talking
> > about.
>
> There are 4 differences.
>
> 1. Existing operators do not change their meaning and therefore
>     all lines containing existing operators can be taken at face value
>     rather than being suspect of hiding some unsuspected behaviour.
>

With operator overloading (if used right) they don't change their
meaning either. + means to add something. You are just changing
the something you want to add.
You could define operator+ to multiply it's parameters ofcourse,
but you could do that using any of the constructs we are talking
about.



> 2. There is a 1:1 relationship between operator and function which enables
>     the programmer to use a simple operator table to figure out what a
> specific
>     equation means

I don't like those tables, and with normal operators you don't need them, you already know what + means.


>
> 3. I recommend that all new operators have the same precedence. Hence
there
>     is no confusion in the order of operations, and no unnatural
> consequences to
>    what would otherwise be automatic reordering.
>

A yes:

Assuming a class int64 with operators defined for adding and multiplication:

int64 a, b, c;

a := a :+ b :* c;

Now you will get different results then you would expect from plus and multiply operations... It just doesn't make sense that all math knowledge becomes invalid when using operators.


> 4. New operators would provide visual cues that readily distinguish them
> from
>     existing operators, thereby allowing the programmer to readily
identify
> new program
>     behaviour.
>

The behaviour for + is not new, it is still adding two entities. You are just allowing new types to be added.


>
>
>
> Odesse writes:
> > Ok, so maybe if people see .= they will look it up
> > in the docs. Or maybe they just assume it is assign. At least
> > with the normal = there is a defined meaning what the
> > operator *should* do. Now it could be anything. I think the
> > code just got much _less_ self-documenting!
>
> Now they could presume it is an assignment, but the colon at the front of the operator indicates new behaviour that distinguishes it from simple assignment.
>

What new behaviour? What strange things are you doing tou your variable?


> You may elect to ignore visual cues like that, but I would not.
>
> On the other hand with overloading you wouldn't see
>
> :=   (colon equal)
>
> you would see
>
> =  (equal)
>
> Which is identical to
>
> =  (equal)
>
> Yet the first equal under your regime of operator overloading would have a
> meaning that is entirely
> different than the second equal symbol,.
>

Right, entirely different. No relation whatsoever. Are you kidding me? I am assigning one variable to another, since when does the assignment of objects of a class have nothing in commom with assigning integers or floats? Should we also use different operators for addition of all basic types? The have "nothing in common" after all...



> Your system, no visual cues.
>
> Your system is inferior.
>
>
>
>
>
> > > OdessE writes:
> > > > Now I doubt that there will be many people telling me the first snippet is more readable than the second.
> > >
> > > Now I dount that there will be many people telling me that
> > >
> > > MyClass::result =  Var1 .+ Var1 .* Var3
> > >
> > > is any less readable than
> > >
> > > MyClass result = Var1 + Var1 * Var3;
> > >
>
> Odesse writes:
> > I am telling it. I never saw an operator .+ before. Not in
> > Delphi/Java/C/C++, nor in math. How am I supposed to
> > know what it means?
>
> You go to the top of the module, find the definition and read it. Alternately you pull out your quick reference chart and read it. Alternately you rememher what it means and continue with the
interpretation.
>
> I fail to see your difficulty.
>

Usability. The code should be as self-documenting as possible. I shouldn't need a quick reference chart, or at least as less as possible.


>
>
> Odesse writes:
> >  I could *assume* it means plus,
> > but I wouldn't know it. At least with normal + I know
> > what it normally means (in math or other languages).
>
> You can assume many things.  The colon in front of the label is a visual cue that you may not assume anythign.
>
> Assume at your own peril.
>

Do you never assume anything about other people's code?
If someone makes a list class and gives it a Add function,
I will assume it means adding something to the list. I am
not going to assume it means removing elements. When
you are programming with an API, say Win32, how do
you find out what function to use? When you need to
create a window, do you really read all the documentation
for all API functions, or are you going to assume that
CreateWindowEx will create a window, and then just
check it's documentation to see what parameters you need?
Assumptions are always made, either conciously or
unconciously. The trick is to make sure those assumptions
are correct, by having operations do what you would
expect them to do.


>
> > > OdessE writes:
> > > > After I wrote
> > > > it, I had to examine it 4 times to make sure I had it correct,
> > > > with all the braces and the order of the arguments.
> > >
> > > I had no such burden.
> > >
> >
> > Good for you, but you are contradicting yourself with this
> > cowboy-coder comment. So if you know what it means
> > than it is not a problem eh?
>
>   Nope, it's not a problem because you can easily remember what it means
> as well.  Most importantly the colon at the front of the label is your cue
> that unusual behaviour is taking place.
>

Excuse me, what colon?  I was talking about an example with named functions, that is why I was mentioning how the braces were confusing to me:

MyClass result.Assign(MyClass::.Add (Var1, MyClass::Multiply (Var1,Var3)));

That was the function I was talking about. Where is the colon?


>
>
> Odesse writes:
> > You still didn't say that
> >
> > MyClass result.Assign(MyClass::.Add (Var1, MyClass::Multiply (Var1,
> Var3)));
> >
> > is more readable than
> >
> > MyClass result = Var1 + Var1 * Var3;
> >
> > probably because it just isn't.
>
> Yes, the first statement is more readable than the second because in the case of the second statement we are not told what + and * do.

Yes we are, by our math teachers when we go to school.
You know what plus is supposed to do. You also know what Add()
is supposed to do. If they really do it is a different matter.
If you can't grasp what + is supposed to do, why would Add()
be more clear? I don't know what

House1 = House2 + House3;

is supposed to do, but then again I don't know what

House1.Assign (House::Add (House2, House3));

is supposed to do either. Do you? Maybe add the windows
in the house?


> We only know that they perform some unknown operation, and that operation depends on the variable types which are not specified.
>

In D the type of all variables is always specified.
The meaning of the Add() operation on the other hand might not be
specified, since it is not required by the languag that it is documented.
All we know is that it is a static function which takes two arguments of
a certain type and returns another argument of that same type. But we
also know that of the + operator. What is the difference?


> Hence we can say nothing about the second function.
>

Nor about the first. All we can do is read the documentation, use our common sense in interpreting well known symbols or variable names and look at the definition or implementation of the functions involved.


>
> However in the case of :+ and :* there is a 1:1 correspondance between function and operator label so knowing that
>
> :* = Myclass::Multiply(Var1,Var3)
> :+ = Myclass::Add(Var1,Var3)
>
> We know everything we need to know about the equation.
>

No we don't. We still don't know what Multiply() does, at least
not when we "may not assume anythign" like you say.
We just added an extra layer of complexity. I now have to
remember that :* calls Multiply and find out what Multiply does.


> It's really quite simple.  I fail to see your objection.
>

Strange. I see your objections, I just don't agree with them.
Do you mean to say you really don't understand what is
being said?


>
>
> > > > > The problem with operator overloading is that it can be highly
> > > confusing.
> > > > > What Isn't highly confusing however, and what does provide the
same
> > > > benefit
> > > > > is providing the ability to create your own operators.
> > >
> > > OdessE writes:
> > > > Mmmm.... So you don't understand what A + B or C * D
> > > > means, but you do understand all of the very complex
> > > > operators that exist in math today, as well as the ones that
> > > > I personally come up with?
> > >
> > > Clearly no one can, since the meaning of + and * are dependent on the
> > types
> > > of A, B, C and D.
>
> Odesse writes:
> > And clearly no one can now the meaning of .+ and .*
>
> Since there is a 1:1 correspondance of  label and funtion, you consult
your
> opcode table.

Great all these tables.


>
> You can not do this with + and * since there are no visual clues that +
and
> * are
> doing anything outside their ordinary meaning.
>
> a = b + c
> d = e + f
>
> In your inferior system of operator overloading the first example above
may
> be
> doing a simple addition,. while the second could be adding a graphic to a
> web page an
> uploading the result to a server.
>
> Quite foolish.

It could also format your harddisk. But so could your :+ operator. There are some visual cues that the operator is overloaded, because the parameters used with it are non-standard. The operator itself looks the same, but so it should. You are performing a standard operation with it, you are just performing it on non-standard parameters. Hence the visual cue should come from the parameters.


>
> Odesse writes:
> > At least with normal operators I know what they usually do and have a reference in math or other languages to draw experience on.
>
>    And you can still use that by creating new operators with names similar
> to the existing operators.  :+ in place of + for example.

They are confusing. Especially the fact that everyone can, and will, define
different operators to perform the same operation on the same types of
variables (say vectors, strings, the boundschecked pointer you would
like) is going to cause a lot of confusion.


>
>   But you have the advantage of creating new operators with more
> appropriate labels as well
>
>   For example :dot or :cross for dot and cross products  If the colon were
> more visible
> on this screen I would have used colon period, for dot product and colon x
> for cross product.

?
You are already using the colon.
:cross looks like a function, not an operator. What is the use of operators
if they have names? You might as well define :add instead of +. The idea
behind operator overloading is to use the notation of the problem domain.
If you are describing a mathematical addition you want to use the
mathematical operator to describe that operation.


>
>   So all of the advantages of operator overloading exist while all of the
> failures of C++ style operator
> overloading can be avoided.
>

None of the advantages exist. You lose the biggest advantage, the fact
that you can use operators from math to represent the mathematical
operations you want to perform. What you are left with is essentialy
a way to hide descriptive function names behind strange self-defined and
thus arbitrary symbols such as :V+. Just a shame you defined :V+ for
Vector math as in matrices and vectors, while someone else defined it
to concatenate java style vectorss. On the other hand, I defined
the addition for math vectors as :+ because it was the only one I
needed, while you thought that one was more appropriate for your
bounded pointer. Do you really mean to say you don't see how this
might cause confusion?


>   Operator overloading is clearly inferior.
> .
>
> > > It depends on what A and B are.and what you are trying to do.  Perhaps
A
> > and
> > > B are objects, the == syntax can have three equally appropriate
> meanigns.
> > A
> > > is numerically identical to B,  A is functionally identical to B, A
and
> B
> > > are the same object.
> > >
> > > With one equal sign, how do you intend to distingish between these
three
> > > poetntial meanings?  How do you intend to implement more than one of
> them
> > at
> > > a time?
> > >
> > > I await your response.
>

To check if the objects were one and the same, you would compare the references, not the object they are pointing to.

To check wheter the objects contain the same information you would check the objects themselves.

> Odesse writes:
> > I don't really see how Cmp solves these issues better then operator
> > overloading.
> > And if you compare two numbers to see if they are equal, do you try to
> find
> > out if the are the same instance of an int? Draw from experience.
>
> That may very well be a requirement yes.  That int may very well be a
> semiphore used
> for synchronization, or used by the program to tell if it is looking at an
> instance of itself.
>
> Once again I fail to see your complaint.
>

How do you do this in C/C++?
You mean

int a;
int *pa
int *pb;

pa = &a;
pb = &b;

if (*pa == *pb)     // same number in instances of int
if (pa == pb)         // same instance of int

I don't see why operator overloading would make this more difficult.
Anyhow, you are not comparing the same objects.
In the first case you are comparing two ints. In the second case you are
comparing two references or pointers to ints. By definition, each instance
of an object is a unique entity.
When you use classes, the operator to compare the pointers to the
classes would be automatically defined, so you compare using that. To
compare not the pointers or references, but the objects themselves, you
need to use Cmp() or an overloaded operator. Your argument does not
hold, simply because you are saying that the comparison operator
can have different meanings when applied to the same type, when in
the example you give they are actually applied to different types, objects
(the ints) and references to these objects. So it makes sense that the
same operation applied to variables of different types yields different
results.

>
>
> Odesse writes:
> > int A = 10;
> > int B = 10;
> > int C = 0;
> >
> > if (A == B)
> >    C = A;
> > B = 5;
> >
> > What value does C have?
>
> If this langauge allows all operators to be overloaded even for the base
> types
> then we do not know the answer because somewhere elsewhere in the program
> the operators may have hand their meaning altered.
>

No one is saying that operators should be overloaded for operations
between base types, so we *do* know what value C has. You are
avoiding the conclusion. If we compare objects we want to know if
they contain the same information. If we want to know if two references
point to the same object, we compare the references, not the objects
themselves. These are two different operations on two different types,
hence they yield two different results.


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