Override Add(Object), and add an in-contract that the class be of type
computer:



class computer : IAddable
{
    Object Add(Object other)
    in
    {
        assert(other.class == computer);
    }
    body
    {
        ....
    }
}



The compiler can optimize out the vast majority of cases, where it knows that the 2nd argument is of class computer.  If you pass something else, it can alert user at compile time: "error: argument passed to computer.Add(Object) breaks in-contract."  For the few cases where the compiler can't know ahead of time, you do a trivial runtime check and throw a BrokenContractException (or whatever) if needed.



Juarez Rudsatz wrote:

> This form could be a very good way of solving the problem for classes. But what the main purpose of operator overloading ?
>
> For me is defining new operations over simple types. The are not strong meaning doing :
>
> computer a, b, c;
> a = new computer(1,2);
> a = new computer(1,7);
> c = a + b;
>
> How could this be done with interfaces.

--
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))) ]

"Juarez Rudsatz" <juarez@correio.com> wrote in message news:a2rqhr$1oln$1@digitaldaemon.com...
> This form could be a very good way of solving the problem for classes. But what the main purpose of operator overloading ?
>
> For me is defining new operations over simple types. The are not strong meaning doing :
>

It is not possible to overload operators for basic types, at least not in C++ or any other language I know.

> computer a, b, c;
> a = new computer(1,2);
> a = new computer(1,7);
> c = a + b;
>

> For example candidates could be
> Date and Time,

Date and Time are usually implemented as doubles
or something, so you can add and subtract them using
normal operators. No need for overloading.

> Grades , Minutes, Seconds
> Celsius <-> Fahrenheit
> Meters <-> Foots
> Kilo, Pounds, etc...

Same here, depending on the implementation, these
are usually implemented as doubles or ints. No need
to do any overloading, you can simply add them.

> Matematic types like complex ( already added ) and so on

> Geometric types

You mean point etc? Define a class.

> Matrix types

You wil need a class.

> , and etc
>
> How could this be done with interfaces.
>

Define a class, then implement the interfaces for the operator you need.


--
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:a2san3$1spl$1@digitaldaemon.com...
> > Geometric types
>
> You mean point etc? Define a class.
>
> > Matrix types
>
> You wil need a class.
>
> > , and etc
> >
> > How could this be done with interfaces.
> >
>
> Define a class, then implement the interfaces for the operator you need.

Unfortunately to provide an interface, you need a vtable.  But most of the uses I find for operator overloading can't tolerate that kind of extra baggage.  Vectors and Matrices, for example.  A struct in D could work, but structs can't provide interfaces.

I personally would be ok with operator overloading only being available for structs, not classes, but I'm not likely to get even that.  ;(

Maybe Walter will generalize the complex type enough that it can be turned into a useful 3 or 4 component vector.  In 3d graphics we don't generally need double precision (though it could be useful in some situations).  We can make arrays of 3 or 4 of those into matrices on our own, and I wouldn't mind having to use functions on just matrices.  But vector math needs operator syntax in a bad way.

If I can just get Walter to provide this type natively I'd be extremely happy (hopefully one of these days it could be optimized for SIMD processors too)

type vector4
   float& operator [0..3]
   float&  .x , .y , .z , .w     // these accessors would be nice
   vector4 operator +  ( vector4,vector4 ) // add components
   vector4 operator - ( vector4,vector4 )
   vector4 operator * ( vector4,vector4 )
   vector4 operator * ( vector4,float )
   vector4& operator += ( vector4 )
   vector4& operator -= ( vector4 )
   vector4& operator *= ( vector4 )
   vector4& operator *= ( float )
   float .length

intrinsic float dot(vector4, vector4)

But it'd probably be nice to have vector2 and vector3 also.  int flavors could be nice too and could use probably 2,3,4, or 8 elements.

Alot of processors have register types like this, but the nice thing about it is that it can all be emulated on the main FPU if necessary.  It's pretty lightweight, I doubt it's hard to implement (no harder than the complex type, anyway) and people that don't need it can ignore it.  People that do need it will be pleased.   ;)

Sean

> --
> Stijn

"Sean L. Palmer" wrote:

> ...
> Maybe Walter will generalize the complex type enough that it can be turned
> into a useful 3 or 4 component vector.  In 3d graphics we don't generally
> need double precision (though it could be useful in some situations).  We
> can make arrays of 3 or 4 of those into matrices on our own, and I wouldn't
> mind having to use functions on just matrices.  But vector math needs
> operator syntax in a bad way.
>
> If I can just get Walter to provide this type natively I'd be extremely happy (hopefully one of these days it could be optimized for SIMD processors too)
>
> type vector4
>    float& operator [0..3]
>    float&  .x , .y , .z , .w     // these accessors would be nice
>    vector4 operator +  ( vector4,vector4 ) // add components
>    vector4 operator - ( vector4,vector4 )
>    vector4 operator * ( vector4,vector4 )
>    vector4 operator * ( vector4,float )
>    vector4& operator += ( vector4 )
>    vector4& operator -= ( vector4 )
>    vector4& operator *= ( vector4 )
>    vector4& operator *= ( float )
>    float .length
>
> intrinsic float dot(vector4, vector4)
>
> But it'd probably be nice to have vector2 and vector3 also.  int flavors could be nice too and could use probably 2,3,4, or 8 elements.
>
> Alot of processors have register types like this, but the nice thing about it is that it can all be emulated on the main FPU if necessary.  It's pretty lightweight, I doubt it's hard to implement (no harder than the complex type, anyway) and people that don't need it can ignore it.  People that do need it will be pleased.   ;)
>
> Sean

I do lots of image processing (especially color space conversions and multispectral interpolations), and I presently make use of the free (as in Beer) Intel libraries.  <drool> If D were to offer vectors as Sean proposes, then the possibility of obtaining screaming native language performance for image processing without the overhead of library calls would exist.  </drool>

Maybe as a future language extension?


-BobC

Sean L. Palmer wrote:

> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message
> news:a2san3$1spl$1@digitaldaemon.com...
> I personally would be ok with operator overloading only being available for
> structs, not classes, but I'm not likely to get even that.  ;(
> 
> Maybe Walter will generalize the complex type enough that it can be turned
> into a useful 3 or 4 component vector.  In 3d graphics we don't generally
> need double precision (though it could be useful in some situations).  We
> can make arrays of 3 or 4 of those into matrices on our own, and I wouldn't
> mind having to use functions on just matrices.  But vector math needs
> operator syntax in a bad way.


While my needs are the same as yours, and float 4-element
vectors and float 4x4-element matrices would cover it,
the astrophysicists will laugh at our puny 23-bit mantissas
and ask where the hell the vectors of double and extended
are. Apart from the SIMD issues, though, the fatter vectors
should be mostly a cut-and-paste operation on Walter's part.

I do agree that the vector that fits in the CPU's SIMD
registers (4x32-bit float in most cases) is the most
important one to offer, though.

-Russell B

Operatoror overloading is an error gnashing at the bit to happen.  There is <NO> valid justification for providing it.  There are arguments, but they are ALL invalid, because code reliability must trump programming convenience.

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.

Existing operators have limited usefulness, even for simple vector operations where there are two types of product.  What existing two operators are you going to redefine for them?

Operator Overloading is very, very bad news.
OddesE <OddesE_XYZ@hotmail.com> wrote in message
news:a2k8u8$fao$1@digitaldaemon.com...
> Ok, so one more time about operator overloading...  :)
>
> I read all the posts about operator overloading but I'm still a bit unsure about it...Do I want it, or don't I...
>
> I like about operator overloading the fact that you
> can add, subtract, compare or assign objects to
> one another much the same way as you can with
> normal primitive types.
>
> I hate some uses of operator overloading which
> seem really confusing to me. I always disliked
> the way cout and cin work.

Your first paragraph shows you to be closed minded.  By that argument, pointers must be removed from the language, as well as anything that can be remotely dangerous such as typecasting.  By the time you're done you won't have much of a language left.

I bet you have problems figuring out what happens when you add a char to a float and then add the result to an int.  The behavior of the operator is governed by the types operated upon and the type conversion rules of the language.  It gets a little more complex with operator overloading on user types, but not to the point of unusability.

I'm not in favor of stripping away language utility to make up for the deficiencies of the lowest common denominator programmer.  Your entire argument is founded on that.  At least people can be trained proper coding technique.  But it's difficult to add functionality to your compiler in most cases (GCC at least allows it, but still not easy).  So removing functionality is just going to cause language holes to exist that will give people great big excuses to use a language that has all the functionality they need, even if that language is C++ and allows you to shoot yourself in the foot.

The main problem with operator overloading is that people don't bother to look up the declaration of the variables they're dealing with.  For this I blame hacks like Hungarian notation.  I'm sure it's something that a strong IDE with one-button or tooltip browse info could solve nicely.

In any case, I expect people on my team to verify that their code works before checking it in.  If you get operator overloading wrong, you'll notice as soon as you run it because the behavior won't be what you expected.  (try to assign the result of a dot product to a vector, or the result of a cross product to a float, and you'll get a type mismatch of some kind at compile time)

Sean


"D" <s_nudds@hotmail.com> wrote in message news:a3liu5$ruq$1@digitaldaemon.com...
>
> Operatoror overloading is an error gnashing at the bit to happen.  There i
s
> <NO> valid justification for providing it.  There are arguments, but they are ALL invalid, because code reliability must trump programming convenience.
>
> 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.
>
> Existing operators have limited usefulness, even for simple vector operations where there are two types of product.  What existing two operators are you going to redefine for them?

D wrote:

> Operatoror overloading is an error gnashing at the bit to happen.  There is <NO> valid justification for providing it.  There are arguments, but they are ALL invalid, because code reliability must trump programming convenience.

(please excuse my slight flamishness coming...)


In a well controlled, well designed situation, programming convenience OFTEN LEADS TO CODE RELIABILITY.  When the code is easy to write and read, and most importantly WHEN IT DOES WHAT IT SEEMS LIKE IT DOES, the two are one and the same.

This whole idea that operator overloading = code confusion is vaporous.  What operator overloading is a convenient shortcut into a certain function syntax. You could argue that "function naming is a bug-prone feature" because a programmer can write a function named one thing that does another.


IT IS THE RESPONSIBILITY OF THE CODE REVIEWERS, IN CONSULTATION WITH THE ORIGINAL PROGRAMMER, TO ENSURE GOOD CODE DESIGN.


Don't leave out an incredibly useful feature just because some people misuse it.  If it's hard to implement in the compiler, I can understand that - we want a small, reliable compiler.  But if it's easy to implement and we're not doing it out of some desire to "protect the user from himself"...well, I didn't become a programmer because I was content with what was "safe and easy."

--
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))) ]

"D" <s_nudds@hotmail.com> wrote in message news:a3liu5$ruq$1@digitaldaemon.com...
>
> Operatoror overloading is an error gnashing at the bit to happen.  There
is
> <NO> valid justification for providing it.  There are arguments, but they are ALL invalid, because code reliability must trump programming convenience.

I wouldn't say that code reliability is that much at stake with operator overloading. Consider the next piece of code:

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

Then consider the same code using operator overloading:

MyClass result = Var1 + Var1 * Var3;

Now I doubt that there will be many people telling me the first snippet is more readable than the second. 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 am not talking about how *writable* the code is, mind
you, that does not seem very important to me. Everyone will
testify that the second part is more easy to write, with less
characters and less parenthesis, but I don't care about that.
I almost never use acronyms like w8 4 me, RTFM, IMHO,
WYSISYG etcetera, because, even though they are easier
to write, they are more difficult to read. But when code is
easier to *read* as well as write, I think that leads to more
reliable code!

> 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.
>

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? This just doesn't make sense
to me...

> Existing operators have limited usefulness, even for simple vector operations where there are two types of product.  What existing two operators are you going to redefine for them?

This example is mentioned often, and it is indeed a very good one. Matrix math is a very important part of programming and indeed there should be a standard for such things. This doesn't put an end to the discussion though...Are there many different ways to interpret A = B, or if (A == B)?  These are the operators used and overloaded most often, and they are valid operations for almost any class you can come up with. What is more readable to you:

if (! A.Cmp (B))

or

if (A == B)

I especially love the fact that there is a ! operator in the first
expression, that to me is quitte counter-intuitive, and that the
==, !=, < and > operators are mixed together, even though
some classes support testing for equality, but not for sortability.
When A.Cmp(B) returns -1, does that mean A is smaller than
B, or that it is just not equal to it? You gotta love that ambiguity!
If a simple test for equality isn't unambiguis and is counter
intuitive, that tells a long story.

> Operator Overloading is very, very bad news.

There are some very bad things that *can* be done with
operator overloading, but there are also some very good.
What my proposal (which you said nothing about) tries to do,
is use the best things of both worlds. It eliminates a lot of the
mistakes that can be made using operator overloading, such
as overloading == but not !=, it allows for both forms of
coding to be used (and even exchanged using DML) and it
could create more readable code.

Walter, *please* create some basic interfaces like IAssignable,
IComparable and ISortable! It would make D code from
different users look and behave the same. We could test if a
class supports ISortable and there would be much less different
ways of doing the same thing. Also, please ditch Cmp(). Testing
for equality and sortability are different things that shouldn't be
mixed like C does.

Even if you don't want to make a decision about operator
overloading just yet, interfaces like this would leave the door open
while gaining important benefits right away! If you never add
operator overloading to the language we at least all use the same
ways of assigning one object to another, or comparing them or
testing which one is larger than the other etc.
I would hate to see some people define assignment functions
as Assign(), others as Copy() and again others as Clone().

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

Sean L. Palmer writes:
> Your first paragraph shows you to be closed minded.  By that argument, pointers must be removed from the language, as well as anything that can
be
> remotely dangerous such as typecasting.  By the time you're done you won't have much of a language left.

  Pointers have their place because they improve efficiency.  Operator
overloading provides no such advantage.  It is simply a convenience feature
for a minute number of situations that in most situations is abused thereby
reducing code quality and maintainance.

  Defining new operators however is a different story.  New operators can
provide the same utility as existing ones without the associated problems of
precidence and predefined meaning that limits the usefulness of the C/C++
implemntation.

  Members of the C religion like to argue that their God is the only God.
When they accuse me of having a closed mind, I laugh.


Sean L. Palmer writes:
> I bet you have problems figuring out what happens when you add a char to a float and then add the result to an int.

I do, because in crap languages like C/C++ the sign of char is not defined in the standard,  the Char may be signed or unsigned and which is left up to the compiler.

What is also wrong with C/C++ is that char is considered numeric at all. That is the height of stupidity.  Rather characters should be relegated to characters, an only available as numbers if they are explicity cast as such.

Members of the C faith will whine.  Let them whine.


Sean L. Palmer writes:
> I'm not in favor of stripping away language utility to make up for the deficiencies of the lowest common denominator programmer.

Clearly you do favour such a thing, since if you did not then youi would be programmig in assembler where you can create what you wish, when you wish. With assembler you have absolute freedom.

So by selecting any HLL or MLL you have already decided to make a tradeoff.

Your whine therefore has no significance, other than to show a reluctance to accept reason.


Sean L. Palmer writes:
>  At least people can be trained proper coding
> technique.  But it's difficult to add functionality to your compiler in
most
> cases (GCC at least allows it, but still not easy).  So removing functionality is just going to cause language holes to exist that will
give
> people great big excuses to use a language that has all the functionality they need, even if that language is C++ and allows you to shoot yourself
in
> the foot.

No.  Language holes exist as a result of features that can not be completely implemented due to compiler constraints, or compile time requirements.

Just as not every mathematical function has an easily computable inverse, not every design characteristic of a language can be fully implemented in concept across the language.  Those areas where the implementation becomes difficult are the areas where there are holes in the language.

One of the holes in the C language is the foolish method chosen to implement autoincrement, and the restrictions placed on the use of the operation in complex  equations.  Rather than have the compiler spend the time to properly implement the function, the morons who invented the C language (may they eternally burn in hell), decided to place the onus on the programmer to use the feature "properly".  I.E. to use the feature in a manner in which the compiler doesn't fail.

Sean L. Palmer writes:
 > The main problem with operator overloading is that people don't bother to
> look up the declaration of the variables they're dealing with.

Wrong.  The main problem with operator overloading is that the given meanings of the exiting operators do not lend themselves to the operations that typically need to be performed.  This results in programmers doing things like using the division operator to compare strings, and stupid things like that.



Sean L. Palmer writes:
> In any case, I expect people on my team to verify that their code works before checking it in.  If you get operator overloading wrong, you'll
notice
> as soon as you run it because the behavior won't be what you expected.
(try
> to assign the result of a dot product to a vector, or the result of a
cross
> product to a float, and you'll get a type mismatch of some kind at compile time)

There are two kinds of product for vectors.  Which of the two existing operators are you going to use to specify them?