Hi,

I don't find any document that say if the operator overloading will be
a new feature of the Java 7

Do anyone know if it there will be?

Thanks

josh wrote:
> Hi,
> 
> I don't find any document that say if the operator overloading will be
> a new feature of the Java 7
> 
> Do anyone know if it there will be?

I don't think so. Why would you want it? Switch to C++ if you need it badly.

I hope they'll do such thing. I wish they forget about closures bit its
already a bit too late.

Regards,
Leonard

-- 
Simplicity is the ultimate sophistication.
                                  -- Leonardo da Vinci

josh wrote:
> Hi,
> 
> I don't find any document that say if the operator overloading will be
> a new feature of the Java 7
> 
> Do anyone know if it there will be?

I don't think so. Why would you want it? Switch to C++ if you need it badly.

I hope they'll never do such thing. I wish they forget about closures 
bit its
already a bit too late.

Regards,
Leonard

-- 
Simplicity is the ultimate sophistication.
                                  -- Leonardo da Vinci

> Simplicity is the ultimate sophistication.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Leo=
nardo da Vinci


for the above quaotation :)

It's better to write:

Time t =3D new Time(2);
Time t2 =3D new Time(4);

Time t3 =3D t + t2;

rather than

Time t3 =3D Time.add(t, t2);

josh wrote:
>> Simplicity is the ultimate sophistication.
>>                                   -- Leonardo da Vinci
> 
> 
> for the above quaotation :)
> 
> It's better to write:
> 
> Time t = new Time(2);
> Time t2 = new Time(4);
> 
> Time t3 = t + t2;
> 
> rather than
> 
> Time t3 = Time.add(t, t2);

Well. It really depends what do you mean by ,,better''. I consider the
lack of operator overloading an advantage because it helps to understand
the code. Also, operator overloading is frequently abused making it very
difficult to analyze the code.

It is not only about reading the code. Think of all the great tools like
IntelliJ IDEA. They exist only because Java is quite easy to analyze
statically. While operator overloading would not prevent static analysis
it would certainly make it harder. Think that it will make cost of
creating good tools higher which means less tools for higher price.

Think of all the people that have to learn Java. With time, Java
Language Specification gets longer and longer as it incorporates more
and more features. While it may be easy for you to learn new features
for the new release, people starting with Java have to learn it all
which gets increasingly harder. In mine opninion things like closures
only pollute language while not helping anything that couldn't be
addressed without them.

Then think that when anything is included into Java we're stuck with it
FOR LIFE or until we change the language for something different.

Isn't it much for changing


Time t3 = Time.add(t, t2);

to

Time t3 = t + t2;

?

Best regards,
Leonard

-- 
Simplicity is the ultimate sophistication.
                                  -- Leonardo da Vinci

On Thu, 8 May 2008, Leonard Milcin wrote:

> josh wrote:
>>> Simplicity is the ultimate sophistication.
>>>                                   -- Leonardo da Vinci
>> 
>> for the above quaotation :)
>> 
>> It's better to write:
>> 
>> Time t = new Time(2);
>> Time t2 = new Time(4);
>> 
>> Time t3 = t + t2;
>> 
>> rather than
>> 
>> Time t3 = Time.add(t, t2);
>
> Well. It really depends what do you mean by ,,better''. I consider the
> lack of operator overloading an advantage because it helps to understand
> the code. Also, operator overloading is frequently abused making it very
> difficult to analyze the code.

No. This is simply FUD and nothing more.

Operator overloading was abused widely in C++; it was abused by the guys 
who designed the standard library (the great Bjarne himself?), and that 
set an example that led to it being abused by other programmers. Smalltalk 
has operator overloading, and it isn't abused there. Python has operator 
overloading, and it isn't abused there either. I can show you any number 
of languages with operator overloading where it isn't abused. There is 
nothing inherent about operator overloading that leads to abuse - the 
problem in C++ is a cultural one, not technical.

Java's designers made the argument you made, and many even have believed 
it, but all this means is that they're traumatised C++ survivors, not that 
they're right.

> It is not only about reading the code. Think of all the great tools like
> IntelliJ IDEA. They exist only because Java is quite easy to analyze
> statically. While operator overloading would not prevent static analysis
> it would certainly make it harder.

No, it would make absolutely no difference whatsoever. The syntax already 
includes operators, and dealing with operators as method calls just 
means treating "+" as a method name.

> Think that it will make cost of creating good tools higher which means 
> less tools for higher price.
>
> Think of all the people that have to learn Java. With time, Java 
> Language Specification gets longer and longer as it incorporates more 
> and more features. While it may be easy for you to learn new features 
> for the new release, people starting with Java have to learn it all 
> which gets increasingly harder.

They already learn how to use operators on primitives (and Strings), so 
that wouldn't be an additional burden for using them on objects.

I doubt very much that learning to write overloaded operators would be 
very difficult - in other languages, they're just like normal method 
declarations, but with a magic word, so we might see:

// C++ style
public Point operator +(Point p) {
 	return new Point((x + p.x), (y + p.y)) ;
}

// python style
public Point __add__(Point p) {
 	return new Point((x + p.x), (y + p.y)) ;
}

// Smalltalk style
public Point +(Point p) {
 	return new Point((x + p.x), (y + p.y)) ;
}

// let's use the hash sign for something!
public Point #add(Point p) {
 	return new Point((x + p.x), (y + p.y)) ;
}

// maybe something with annotations
@operator(symbol="+")
public Point add(Point p) {
 	return new Point((x + p.x), (y + p.y)) ;
}

In any case, if you think it is too hard, just leave it for an advanced 
chapter. There's no huge need to teach people to write overloaded 
operators right at the start. In fact, it might be better not to!

> In mine opninion things like closures only pollute language while not 
> helping anything that couldn't be addressed without them.

Oh, surely you're kidding me? I take it this means you've never used a 
language with closures? One of the best things about python, one of the 
things that meant i never looked back when i switched to it from java, was 
the existence of lambda expressions, functions as first-class objects, and 
higher-order functions.

> Then think that when anything is included into Java we're stuck with it 
> FOR LIFE or until we change the language for something different.

Yes. And both closures and operator overloading are features which are 
well-enough understood in other languages that there is essentially no 
risk in adopting them in java.

> Isn't it much for changing
>
> Time t3 = Time.add(t, t2);
>
> to
>
> Time t3 = t + t2;
>
> ?

For your next exercise, try some matrix algebra with and without operator 
overloading.

tom

-- 
Got a revolution behind my eyes - We got to get up and organise

Tom Anderson <twic@urchin.earth.li> quotes:
>>>Time t3 = t + t2;

  From a person who is not a native speaker of English:
  Is this pronounced �T plus T two�, �T add T two�,
  or in yet another way?

>>>Time t3 = Time.add(t, t2);

  If the previous sum was not pronounced using �add�, 
  why is �add� used here instead of the pronounced word?

Supersedes: <plus-20080508173952@ram.dialup.fu-berlin.de>

Tom Anderson <twic@urchin.earth.li> quotes:
>>>Time t3 = t + t2;

  From a person who is not a native speaker of English:
  Is this pronounced �T plus T two�, �T add T two�,
  or in yet another way?

  If the previous sum was not pronounced using �add�, 
  why is �add� often used in expressions like

t.add( t2 )

  instead of the word pronounced for the operator above?

On May 8, 11:19=A0am, Tom Anderson <t...@urchin.earth.li> wrote:
> On Thu, 8 May 2008, Leonard Milcin wrote:
> > josh wrote:
> >>> Simplicity is the ultimate sophistication.
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --=
 Leonardo da Vinci
>
> >> for the above quaotation :)
>
> >> It's better to write:
>
> >> Time t =3D new Time(2);
> >> Time t2 =3D new Time(4);
>
> >> Time t3 =3D t + t2;
>
> >> rather than
>
> >> Time t3 =3D Time.add(t, t2);
>
> > Well. It really depends what do you mean by ,,better''. I consider the
> > lack of operator overloading an advantage because it helps to understand=

> > the code. Also, operator overloading is frequently abused making it very=

> > difficult to analyze the code.
>
> No. This is simply FUD and nothing more.
>
> Operator overloading was abused widely in C++; it was abused by the guys
> who designed the standard library (the great Bjarne himself?), and that
> set an example that led to it being abused by other programmers. Smalltalk=

> has operator overloading, and it isn't abused there. Python has operator
> overloading, and it isn't abused there either. I can show you any number
> of languages with operator overloading where it isn't abused. There is
> nothing inherent about operator overloading that leads to abuse - the
> problem in C++ is a cultural one, not technical.
>
> Java's designers made the argument you made, and many even have believed
> it, but all this means is that they're traumatised C++ survivors, not that=

> they're right.
>
> > It is not only about reading the code. Think of all the great tools like=

> > IntelliJ IDEA. They exist only because Java is quite easy to analyze
> > statically. While operator overloading would not prevent static analysis=

> > it would certainly make it harder.
>
> No, it would make absolutely no difference whatsoever. The syntax already
> includes operators, and dealing with operators as method calls just
> means treating "+" as a method name.
>
> > Think that it will make cost of creating good tools higher which means
> > less tools for higher price.
>
> > Think of all the people that have to learn Java. With time, Java
> > Language Specification gets longer and longer as it incorporates more
> > and more features. While it may be easy for you to learn new features
> > for the new release, people starting with Java have to learn it all
> > which gets increasingly harder.
>
> They already learn how to use operators on primitives (and Strings), so
> that wouldn't be an additional burden for using them on objects.
>
> I doubt very much that learning to write overloaded operators would be
> very difficult - in other languages, they're just like normal method
> declarations, but with a magic word, so we might see:
>
> // C++ style
> public Point operator +(Point p) {
> =A0 =A0 =A0 =A0 return new Point((x + p.x), (y + p.y)) ;
>
> }
>
> // python style
> public Point __add__(Point p) {
> =A0 =A0 =A0 =A0 return new Point((x + p.x), (y + p.y)) ;
>
> }
>
> // Smalltalk style
> public Point +(Point p) {
> =A0 =A0 =A0 =A0 return new Point((x + p.x), (y + p.y)) ;
>
> }
>
> // let's use the hash sign for something!
> public Point #add(Point p) {
> =A0 =A0 =A0 =A0 return new Point((x + p.x), (y + p.y)) ;
>
> }
>
> // maybe something with annotations
> @operator(symbol=3D"+")
> public Point add(Point p) {
> =A0 =A0 =A0 =A0 return new Point((x + p.x), (y + p.y)) ;
>
> }
>
> In any case, if you think it is too hard, just leave it for an advanced
> chapter. There's no huge need to teach people to write overloaded
> operators right at the start. In fact, it might be better not to!
>
> > In mine opninion things like closures only pollute language while not
> > helping anything that couldn't be addressed without them.
>
> Oh, surely you're kidding me? I take it this means you've never used a
> language with closures? One of the best things about python, one of the
> things that meant i never looked back when i switched to it from java, was=

> the existence of lambda expressions, functions as first-class objects, and=

> higher-order functions.
>
> > Then think that when anything is included into Java we're stuck with it
> > FOR LIFE or until we change the language for something different.
>
> Yes. And both closures and operator overloading are features which are
> well-enough understood in other languages that there is essentially no
> risk in adopting them in java.
>
> > Isn't it much for changing
>
> > Time t3 =3D Time.add(t, t2);
>
> > to
>
> > Time t3 =3D t + t2;
>
> > ?
>
> For your next exercise, try some matrix algebra with and without operator
> overloading.

It might be instructive to think about how foreach was made
extensible: there is an interface which, if implemented properly, can
make an arbitrary class usable in a for(each) loop.  The same could be
done to map syntax to operations:

public interface java.lang.Indexed<T> {
  public T get (int i);
}

would, hypothetically, be enough to allow arbitrary classes to be used
on the left of array expressions like:

Indexed<String> notAnArray =3D new MyClass ("foo", "bar");
assert notAnArray[0] =3D=3D "foo"; // notAnArray.get (0)
assert notAnArray[1] =3D=3D "bar"; // notAnArray.get (1)

However, it's not clear whether the core operators (+, *, /, binary -,
unary -, ++, --) should be exposed as a single interface (Arithmetic),
several interfaces (Addable, Multipliable, Dividable/Rational, etc).

There are also some weird edge cases (like time) where the operands
and result of operations are not the same type.  Consider:

public class Instant { ... defines a precise moment in time ... }
public class Interval { ... defines the amount of time that passes
between two Instants ... }

I'd normally want

Instant a =3D ..., b =3D ...;
Interval duration =3D a - b;

and not

Instant difference =3D a - b;

Similarly, I'd want

Instant a =3D ...;
Interval b =3D ...;
Instant future =3D a + b; // or b + a

Some points to consider...
-o

Stefan Ram wrote:
> Tom Anderson <twic@urchin.earth.li> quotes:
>>>> Time t3 = t + t2;
> 
>   From a person who is not a native speaker of English:
>   Is this pronounced �T plus T two�, �T add T two�,
>   or in yet another way?

At least one native speaker of English would always pronounce it as "tee 
plus tee two".

>>>> Time t3 = Time.add(t, t2);
> 
>   If the previous sum was not pronounced using �add�, 
>   why is �add� used here instead of the pronounced word?

I can't speak for the OP but I would do it that way because it more 
closely follows English grammar, in terms of word order at least.

Consider:
   "Add salt to water"
   "Add salt and pepper"
Although, of course you can always change the word order by expressing 
the idea in a more complex and awkward fashion.

If I wanted to be consistent with the normal pronunciation of "+", I 
would write something like:
   Time t3 = t.plus(t2);
But that might not be a good example of Java style - I'm not sure 
whether Java programmers would expect the value of t to be altered.



BTW It doesn't really make sense (to me) to add two times together. What 
is 1 p.m today plus half past three yesterday?

Another language has data types of DateTime and Interval and allows 
Intervals to be added to DateTimes.


-- 
RGB

RedGrittyBrick <RedGrittyBrick@SpamWeary.foo> writes:
>BTW It doesn't really make sense (to me) to add two times together. What 
>is 1 p.m today plus half past three yesterday?

  It should be something like:

final Instant instant = new Instant( "2008-05-08T18:12:41+02:00" );
final Interval interval = new Intervall( "02:00:00" );
final Instant instant1 = instant.plus( interval );

josh wrote:
>> Simplicity is the ultimate sophistication.
>>                                   -- Leonardo da Vinci
> 
> 
> for the above quaotation :)
> 
> It's better to write:
> 
> Time t = new Time(2);
> Time t2 = new Time(4);
> 
> Time t3 = t + t2;
> 
> rather than
> 
> Time t3 = Time.add(t, t2);

I don't find correct adding two Times.
I think is more correct adding a Time to a TimeSpan.
With or without operators.

-- 
Andrea Francia
alias rm='trash' #use trash command instead of removing
rm -Rfv file     #put the file in the KDE trashcan
http://www.andreafrancia.it/trash

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-71736375-1210268535=:17425
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 8 May 2008, Stefan Ram wrote:

> Supersedes: <plus-20080508173952@ram.dialup.fu-berlin.de>
>
> Tom Anderson <twic@urchin.earth.li> quotes:
>>>> Time t3 = t + t2;
>
>  From a person who is not a native speaker of English:
>  Is this pronounced �T plus T two�, �T add T two�,
>  or in yet another way?

Always "plus" for me.

>  If the previous sum was not pronounced using �add�,
>  why is �add� often used in expressions like
>
> t.add( t2 )
>
>  instead of the word pronounced for the operator above?

It's traditional to use verbs for method names. 'Add' is a verb; 'plus' 
isn't. I would say that in this case, 'plus' might well be a better name, 
because this:

a.plus(b.times(c)).dividedBy(d)

Reads better than this:

a.add(b.multiply(c)).divide(d)

tom

-- 
Got a revolution behind my eyes - We got to get up and organise
---910079544-71736375-1210268535=:17425--

On Thu, 8 May 2008, Owen Jacobson wrote:

> It might be instructive to think about how foreach was made extensible: 
> there is an interface which, if implemented properly, can make an 
> arbitrary class usable in a for(each) loop.  The same could be done to 
> map syntax to operations:
>
> public interface java.lang.Indexed<T> {
>  public T get (int i);
> }
>
> would, hypothetically, be enough to allow arbitrary classes to be used
> on the left of array expressions like:
>
> Indexed<String> notAnArray = new MyClass ("foo", "bar");
> assert notAnArray[0] == "foo"; // notAnArray.get (0)
> assert notAnArray[1] == "bar"; // notAnArray.get (1)

That's a bloody good idea. Well, it might be ...

> However, it's not clear whether the core operators (+, *, /, binary -, 
> unary -, ++, --) should be exposed as a single interface (Arithmetic), 
> several interfaces (Addable, Multipliable, Dividable/Rational, etc).

Both. The joy of multiple inheritance of interfaces!

You need to be able to have things which you can, say, add and multiply, 
but not divide - anything a mathematician would call a ring, like a 
three-by-three matrix. Forcing these to have divide methods that just 
threw an exception would be pretty poor.

You could even model a little hierarchy on discrete mathematics: Addable, 
Multipliable, Ring extends Addable, Multipliable, Dividable, Field extends 
Ring, Dividable, etc.

> There are also some weird edge cases (like time) where the operands
> and result of operations are not the same type.

There are also some distinctly non-weird non-edge cases where this is 
true, and where the operands are not the same type, and where you want to 
be able to overload the operators according to operand type. An obvious 
example would be a Vector3D; i want to be able to add two vectors to make 
a third, but also to multiply a vector by a double to get a vector, and a 
vector by a vector to get their dot product, which is a double. If i also 
have Matrix3D (being a 3 x 3 matrix, to represent linear transformations), 
i want to be able to add matrices, to multiply two to make a third 
(although i have no idea what the geometric significance of that is!), to 
multiply a matrix by a vector to make a transformed vector, etc.

I can't see how you'd do this with interfaces unless they were defined as 
taking Object and returning Object, which would be a bit lame. Like how 
equals and compareTo work.

tom

-- 
Got a revolution behind my eyes - We got to get up and organise

josh wrote:
> Hi,
> 
> I don't find any document that say if the operator overloading will be
> a new feature of the Java 7
> 
> Do anyone know if it there will be?

There are proposals, in great contention as always, but the answer right 
now is "probably not." I have somewhere some ancient links on the matter 
(~1 year old); if you want, I could try to dredge them up.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Tom Anderson wrote:
> I doubt very much that learning to write overloaded operators would be 
> very difficult - in other languages, they're just like normal method 
> declarations, but with a magic word, so we might see:

[ snip styles ]

This is the kind of style I've envisioned myself:

public class Point implements Addable<Point, Point> {
    // etc.
    public Point add(Point p) {
        return new Point((x + p.x), (y + p.y));
    }
}

with Addable of course being:
public interface Addable<A,R> {
    public R add(A addend);
}


>> In mine opninion things like closures only pollute language while not 
>> helping anything that couldn't be addressed without them.
> 
> Oh, surely you're kidding me? I take it this means you've never used a 
> language with closures? One of the best things about python, one of the 
> things that meant i never looked back when i switched to it from java, 
> was the existence of lambda expressions, functions as first-class 
> objects, and higher-order functions.

Bloch (I think it was him) had a presentation a while back on why 
closures and Java don't mix; I myself was irrevocably convinced that 
they were a poor idea when I saw that "return" and "return;" would mean 
different things under the BGGA proposal (and then some people arguing 
that the differences were "obvious"). Java's a great object-oriented 
language; don't try to force it to become a functional one as well.

>> Then think that when anything is included into Java we're stuck with 
>> it FOR LIFE or until we change the language for something different.
> 
> Yes. And both closures and operator overloading are features which are 
> well-enough understood in other languages that there is essentially no 
> risk in adopting them in java.

As Bloch points out in his presentation, there is a high risk. It mixes 
with generics and autoboxing in such a way that some things that seem 
like they should work just plain don't and can't. There is also the 
great chance that you end up with a situation not unlike what happened 
with generics: it goes only halfway and you end up with some aggravating 
problems.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Leonard Milcin wrote:
> I hope they'll do such thing. I wish they forget about closures bit its
> already a bit too late.

My personal take on the matter is that closures will not make it into 
Java 7. I took a survey of this newsgroup about some proposed Java 7 
features, and closures was mostly met with indifference. If I 
extrapolate, I would say that most programmers won't care, and a little 
more will lobby against it than will lobby for it. Certainly, a little 
bit of anti-BGGA press would go a long way to killing it, if you really 
want to do so.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Joshua Cranmer <Pidgeot18@verizon.invalid> writes:
>My personal take on the matter is that closures will not make it into 
>Java 7. I took a survey of this newsgroup about some proposed Java 7 
>features, and closures was mostly met with indifference.

  But, when one goes to night clubs asking young women:

http://bp0.blogger.com/_lfuDZjhLbAM/RsjUjleoCfI/AAAAAAAAACU/IXyIrODh2nM/s1600/P8180010.jpg
http://bp3.blogger.com/_lfuDZjhLbAM/RsjU8VeoCgI/AAAAAAAAACc/ZRh0eqEGef0/s1600/P8180004.JPG
http://bp3.blogger.com/_lfuDZjhLbAM/RsjVTVeoChI/AAAAAAAAACk/7OAqSfZZogg/s1600/P8180009.jpg
http://bp3.blogger.com/_lfuDZjhLbAM/RsjVuVeoCiI/AAAAAAAAACs/lTnXY4GyHf4/s1600-h/P8180012.jpg

  (I experience server problems with some of these pictures
  right now, but some were visible.)

On Thu, 8 May 2008 04:47:53 -0700 (PDT), josh <xdevel1999@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>I don't find any document that say if the operator overloading will be
>a new feature of the Java 7

Usually when the matter comes up, there is a quite a squawk of "over
my dead bodies".

My view is user defined operators with new names/symbols would be
acceptable, but overloading ordinary >> to do I/O is as C++ is an
abomination.  Unicode has lots of symbols you could use as
user-defined operators.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Roedy Green wrote:
> On Thu, 8 May 2008 04:47:53 -0700 (PDT), josh <xdevel1999@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
> 
>> I don't find any document that say if the operator overloading will be
>> a new feature of the Java 7
> 
> Usually when the matter comes up, there is a quite a squawk of "over
> my dead bodies".
> 
> My view is user defined operators with new names/symbols would be
> acceptable, but overloading ordinary >> to do I/O is as C++ is an
> abomination.  Unicode has lots of symbols you could use as
> user-defined operators.

How about the use of "+" for e.g. complex number addition? Can you
suggest a better choice of symbol?

Patricia

On May 8, 1:52=A0pm, Tom Anderson <t...@urchin.earth.li> wrote:

> You need to be able to have things which you can, say, add and multiply,
> but not divide - anything a mathematician would call a ring, like a
> three-by-three matrix. Forcing these to have divide methods that just
> threw an exception would be pretty poor.
>
> You could even model a little hierarchy on discrete mathematics: Addable,
> Multipliable, Ring extends Addable, Multipliable, Dividable, Field extends=

> Ring, Dividable, etc.

The question is, at the language and standard library level, do you
provide four interfaces (for +, *, /, and -) or one (for all four) or
five (both) or some other combination?  If you provide an interface
for each operator, obviously applications can define their own
composite interfaces, but there may be places where the standard
library uses multiple operators on a single type, so there might end
up being some "standard" composite interfaces while other combinations
of operators are unrepresented.  If you include every possible
combination of operators in the standard library, you end up with a
huge number of mostly-useless interfaces.

It's a hard question.

(And that doesn't even get into operators like ++ and +=3D; I'd probably
prefer to have +=3D, at least, implemented automatically in terms of +
instead of being its own operator, but it's not a clear choice.)

> On Thu, 8 May 2008, Owen Jacobson wrote:
> > There are also some weird edge cases (like time) where the operands
> > and result of operations are not the same type.
>
> There are also some distinctly non-weird non-edge cases where this is
> true, and where the operands are not the same type, and where you want to
> be able to overload the operators according to operand type. An obvious
> example would be a Vector3D; i want to be able to add two vectors to make
> a third, but also to multiply a vector by a double to get a vector, and a
> vector by a vector to get their dot product, which is a double. If i also
> have Matrix3D (being a 3 x 3 matrix, to represent linear transformations),=

> i want to be able to add matrices, to multiply two to make a third
> (although i have no idea what the geometric significance of that is!), to
> multiply a matrix by a vector to make a transformed vector, etc.
>
> I can't see how you'd do this with interfaces unless they were defined as
> taking Object and returning Object, which would be a bit lame.

As others have already suggested, a solution like

public interface Addable<A, S> {
  public S add (A addend);
}

with generic "S"um and "A"ddend types makes the most sense.  It's
just, like so much in Java, unpleasantly verbose in the simple case --
a number-like class (for example, BigDecimal) would become

public class BigDecimal implements Addable<BigDecimal, BigDecimal>,
Comparable<BigDecimal>, ...;

That's a lot of "BigDecimal"s.  And since BD is not final, most of
those generic types might have to be ? extends BigDecimal.

> Like how equals and compareTo work.

Comparable is a generic interface (and under this scheme I'd recommend
just using it as-is to implement >, <, <=3D, and >=3D), so its compareTo
method takes "the right type".

Actually, that highlights another issue -- what to do with comparison
operators?  =3D=3D has a well-understood existing meaning (identity
comparison) that would be *very* expensive to change, as do =3D and !=3D;
=3D=3D=3D, :=3D, !=3D=3D, =3D!, and <> are all ugly options.

-o

On Thu, 8 May 2008, Stefan Ram wrote:

> Joshua Cranmer <Pidgeot18@verizon.invalid> writes:
>> My personal take on the matter is that closures will not make it into
>> Java 7. I took a survey of this newsgroup about some proposed Java 7
>> features, and closures was mostly met with indifference.
>
>  But, when one goes to night clubs asking young women:

You apparently find some very ugly young women.

But yeah, chicks be *insane* for functional programming. When they know 
you can take them to a higher order without mutating their state, they're 
all over you like warts on a Redmond C program.

tom

-- 
For the first few years I ate lunch with he mathematicians. I soon found
that they were more interested in fun and games than in serious work,
so I shifted to eating with the physics table. There I stayed for a
number of years until the Nobel Prize, promotions, and offers from
other companies, removed most of the interesting people. So I shifted
to the corresponding chemistry table where I had a friend. At first I
asked what were the important problems in chemistry, then what important
problems they were working on, or problems that might lead to important
results. One day I asked, "if what they were working on was not important,
and was not likely to lead to important things, they why were they working
on them?" After that I had to eat with the engineers! -- R. W. Hamming

On Thu, 8 May 2008, Roedy Green wrote:

> On Thu, 8 May 2008 04:47:53 -0700 (PDT), josh <xdevel1999@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> I don't find any document that say if the operator overloading will be
>> a new feature of the Java 7
>
> Usually when the matter comes up, there is a quite a squawk of "over
> my dead bodies".
>
> My view is user defined operators with new names/symbols would be 
> acceptable, but overloading ordinary >> to do I/O is as C++ is an 
> abomination.  Unicode has lots of symbols you could use as user-defined 
> operators.

As Patricia pointed out, this doesn't help the rather major case of 
wanting to do maths on compound types with conventional operators.

I said it before and i'll say it again: the crimes committed in C++ 
reflect cultural, not technical, problem. Other languages let you overload 
<< and >>, amongst other things, and haven't seen any abuse at all.

tom

-- 
For the first few years I ate lunch with he mathematicians. I soon found
that they were more interested in fun and games than in serious work,
so I shifted to eating with the physics table. There I stayed for a
number of years until the Nobel Prize, promotions, and offers from
other companies, removed most of the interesting people. So I shifted
to the corresponding chemistry table where I had a friend. At first I
asked what were the important problems in chemistry, then what important
problems they were working on, or problems that might lead to important
results. One day I asked, "if what they were working on was not important,
and was not likely to lead to important things, they why were they working
on them?" After that I had to eat with the engineers! -- R. W. Hamming

Tom Anderson <twic@urchin.earth.li> writes:
>>But, when one goes to night clubs asking young women:
>You apparently find 

  I have not made these photographs, but was not able to 
  find the page containing the name of the photographer.

On Thu, 8 May 2008, Joshua Cranmer wrote:

> Tom Anderson wrote:
>
>>> In mine opninion things like closures only pollute language while not 
>>> helping anything that couldn't be addressed without them.
>> 
>> Oh, surely you're kidding me? I take it this means you've never used a 
>> language with closures? One of the best things about python, one of the 
>> things that meant i never looked back when i switched to it from java, was 
>> the existence of lambda expressions, functions as first-class objects, and 
>> higher-order functions.
>
> Bloch (I think it was him) had a presentation a while back on why 
> closures and Java don't mix; I myself was irrevocably convinced that 
> they were a poor idea when I saw that "return" and "return;" would mean 
> different things under the BGGA proposal (and then some people arguing 
> that the differences were "obvious").

Interesting. I need to look this up - Josh Bloch is a smart guy. I'm not 
familiar with the BGGA proposal, so i should read up on that too.

> Java's a great object-oriented language; don't try to force it to become 
> a functional one as well.

I simply don't buy that the two are non-orthogonal.

>>> Then think that when anything is included into Java we're stuck with it 
>>> FOR LIFE or until we change the language for something different.
>> 
>> Yes. And both closures and operator overloading are features which are 
>> well-enough understood in other languages that there is essentially no risk 
>> in adopting them in java.
>
> As Bloch points out in his presentation, there is a high risk. It mixes 
> with generics and autoboxing in such a way that some things that seem 
> like they should work just plain don't and can't. There is also the 
> great chance that you end up with a situation not unlike what happened 
> with generics: it goes only halfway and you end up with some aggravating 
> problems.

I really do need to read up on this!

The only counterargument i can offer is that there are plenty of other 
languages out there that very successfully mix object-orientation and 
closures etc. Saying that it wouldn't work in Java is special pleading, 
and i don't buy it.

I'm not saying that the BGGA proposal isn't duff. But there's a difference 
between one proposal being duff and the whole idea being duff.

tom

-- 
For the first few years I ate lunch with he mathematicians. I soon found
that they were more interested in fun and games than in serious work,
so I shifted to eating with the physics table. There I stayed for a
number of years until the Nobel Prize, promotions, and offers from
other companies, removed most of the interesting people. So I shifted
to the corresponding chemistry table where I had a friend. At first I
asked what were the important problems in chemistry, then what important
problems they were working on, or problems that might lead to important
results. One day I asked, "if what they were working on was not important,
and was not likely to lead to important things, they why were they working
on them?" After that I had to eat with the engineers! -- R. W. Hamming

On Fri, 09 May 2008 00:48:48 +0100, Tom Anderson <twic@urchin.earth.li>  
wrote:

> On Thu, 8 May 2008, Roedy Green wrote:
>
>> On Thu, 8 May 2008 04:47:53 -0700 (PDT), josh <xdevel1999@gmail.com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> I don't find any document that say if the operator overloading will be
>>> a new feature of the Java 7
>>
>> Usually when the matter comes up, there is a quite a squawk of "over
>> my dead bodies".
>>
>> My view is user defined operators with new names/symbols would be  
>> acceptable, but overloading ordinary >> to do I/O is as C++ is an  
>> abomination.  Unicode has lots of symbols you could use as user-defined  
>> operators.
>
> As Patricia pointed out, this doesn't help the rather major case of  
> wanting to do maths on compound types with conventional operators.
>
> I said it before and i'll say it again: the crimes committed in C++  
> reflect cultural, not technical, problem. Other languages let you  
> overload << and >>, amongst other things, and haven't seen any abuse at  
> all.

The most useful thing Sun could do would be at least to overload the  
arithmetic operators to work with BigDecimal and BigInteger.  I believe it  
is this that has been proposed for Java 7, rather than general-purpose,  
user-defined operator overloading.

Alex Miller maintains a page detailing the current status and latest news  
surrounding the various Java 7 proposals:

http://tech.puredanger.com/java7/

Dan.

-- 
Daniel Dyer
http://www.uncommons.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-895386277-1210291270=:10697
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; FORMAT=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <Pine.LNX.4.64.0805090101241.17330@urchin.earth.li>

On Thu, 8 May 2008, Owen Jacobson wrote:

> On May 8, 1:52�pm, Tom Anderson <t...@urchin.earth.li> wrote:
>
>> You need to be able to have things which you can, say, add and multiply,
>> but not divide - anything a mathematician would call a ring, like a
>> three-by-three matrix. Forcing these to have divide methods that just
>> threw an exception would be pretty poor.
>>
>> You could even model a little hierarchy on discrete mathematics: Addable,
>> Multipliable, Ring extends Addable, Multipliable, Dividable, Field extends
>> Ring, Dividable, etc.
>
> The question is, at the language and standard library level, do you 
> provide four interfaces (for +, *, /, and -) or one (for all four) or 
> five (both) or some other combination?  If you provide an interface for 
> each operator, obviously applications can define their own composite 
> interfaces, but there may be places where the standard library uses 
> multiple operators on a single type, so there might end up being some 
> "standard" composite interfaces while other combinations of operators 
> are unrepresented.

Are there really things which can be added and divided but not multiplied? 
How often will it be a problem that there isn't an interface for this?

> If you include every possible combination of operators in the standard 
> library, you end up with a huge number of mostly-useless interfaces.

Which is a pretty fair description of the standard library at present!

> (And that doesn't even get into operators like ++ and +=; I'd probably 
> prefer to have +=, at least, implemented automatically in terms of + 
> instead of being its own operator, but it's not a clear choice.)

There are times when being able to override += would be useful, because 
using + to synthesise it involves throwing away an object, and if they're 
heavyweight, that's not great. If your objects are million-by-million 
matrices, for instance, you'd really like to be able to add in place.

One thing we definitely shouldn't have is overriding of the = operator, 
as C++ lets you do. That's just insane. Ditto the . operator.

"Yes, but you can do some really clever things with those!", the C++ 
brains cry. Yeah, and i'll do something really clever with *your face* if 
you try it, says i.

>> On Thu, 8 May 2008, Owen Jacobson wrote:
>>> There are also some weird edge cases (like time) where the operands
>>> and result of operations are not the same type.
>>
>> There are also some distinctly non-weird non-edge cases where this is
>> true, and where the operands are not the same type, and where you want to
>> be able to overload the operators according to operand type. An obvious
>> example would be a Vector3D; i want to be able to add two vectors to make
>> a third, but also to multiply a vector by a double to get a vector, and a
>> vector by a vector to get their dot product, which is a double. If i also
>> have Matrix3D (being a 3 x 3 matrix, to represent linear transformations),
>> i want to be able to add matrices, to multiply two to make a third
>> (although i have no idea what the geometric significance of that is!), to
>> multiply a matrix by a vector to make a transformed vector, etc.
>>
>> I can't see how you'd do this with interfaces unless they were defined as
>> taking Object and returning Object, which would be a bit lame.
>
> As others have already suggested, a solution like
>
> public interface Addable<A, S> {
>  public S add (A addend);
> }
>
> with generic "S"um and "A"ddend types makes the most sense.  It's
> just, like so much in Java, unpleasantly verbose in the simple case --
> a number-like class (for example, BigDecimal) would become
>
> public class BigDecimal implements Addable<BigDecimal, BigDecimal>,
> Comparable<BigDecimal>, ...;
>
> That's a lot of "BigDecimal"s.

A bit of syntactic sugar which let 'this' stand for the current declaring 
class might help.

> And since BD is not final, most of those generic types might have to be 
> ? extends BigDecimal.

Urgh, is that how generics work? I'm not very au fait with them.

Also, can i declare:

public class Vector implements Multipliable<double, Vector>, 
Multipliable<Vector, double>, Multipliable<Matrix, Vector>

?

>> Like how equals and compareTo work.
>
> Comparable is a generic interface (and under this scheme I'd recommend
> just using it as-is to implement >, <, <=, and >=), so its compareTo
> method takes "the right type".
>
> Actually, that highlights another issue -- what to do with comparison
> operators?  == has a well-understood existing meaning (identity
> comparison) that would be *very* expensive to change, as do = and !=;
> ===, :=, !==, =!, and <> are all ugly options.

I don't see what's so bad about === and !==. In an ideal world, where we 
had operator overloading from the start, ==/!= would be the ones that punt 
to equals(), and ===/!== would be the ones that do identity. Like in pyhon 
:).

tom

-- 
For the first few years I ate lunch with he mathematicians. I soon found
that they were more interested in fun and games than in serious work,
so I shifted to eating with the physics table. There I stayed for a
number of years until the Nobel Prize, promotions, and offers from
other companies, removed most of the interesting people. So I shifted
to the corresponding chemistry table where I had a friend. At first I
asked what were the important problems in chemistry, then what important
problems they were working on, or problems that might lead to important
results. One day I asked, "if what they were working on was not important,
and was not likely to lead to important things, they why were they working
on them?" After that I had to eat with the engineers! -- R. W. Hamming
---910079544-895386277-1210291270=:10697--

On Fri, 8 May 2008, Stefan Ram wrote:

> Tom Anderson <twic@urchin.earth.li> writes:
>>> But, when one goes to night clubs asking young women:
>> You apparently find
>
>  I have not made these photographs, but was not able to
>  find the page containing the name of the photographer.

I realise that, i apologise if i gave the impression otherwise. I meant 
'you' in the sense of 'one'.

tom

-- 
.... the gripping first chapter, which literally grips you because it's
printed on a large clamp.

On May 8, 8:10=A0pm, Tom Anderson <t...@urchin.earth.li> wrote:
> On Thu, 8 May 2008, Owen Jacobson wrote:
> > On May 8, 1:52=A0pm, Tom Anderson <t...@urchin.earth.li> wrote:
> >
> >> You could even model a little hierarchy on discrete mathematics: Addabl=
e,
> >> Multipliable, Ring extends Addable, Multipliable, Dividable, Field exte=
nds
> >> Ring, Dividable, etc.
>
> > The question is, at the language and standard library level, do you
> > provide four interfaces (for +, *, /, and -) or one (for all four) or
> > five (both) or some other combination?

It's worth looking at the way Haskell handles operator overloading and
numeric types here.  There is a class of types, Num, which represent
"numbers": integers, reals, rationals, complex numbers, oddities like
quaternions, presumably the tensor family, whatever.  Num provides +,
-, *, negate (used for unary -), and abs functions, and inherits
equality testing from the Eq class.

Num has a subclass, Real, which also subclasses Haskell's Ord class,
which in turn provides comparison operators.  This is the root of most
the more common numeric types, not Num.

Real has two subclasses: Integral and Fractional.  Both provide the /
operation; the difference is in the result type.  Integral in turn has
two subclasses: Integer, which are bigints, and Int, which are
intended to be machine ints.  Dividing two Integral values can only
produce another Integral; Integral also provides remainder and mod
operations.

Fractional's standard instances are the Float and Double types, which
map to what you'd expect from other languages.  Fractional specifies
a / operator as well as a few other useful things.

Due to the way type classes work in Haskell it's extremely easy to add
new numeric types at arbitrary points in this tree and have them work
"as expected" with existing code.  Your hypothetical Giant Matrix type
would likely be an instance of Num, and would add some operators of
its own to allow for multiplication by non-Giant Matrix values like
Reals.

> > If you include every possible combination of operators in the standard
> > library, you end up with a huge number of mostly-useless interfaces.
>
> Which is a pretty fair description of the standard library at present!

You've a call from the org.omg package complaining about unfair
representation.  ;)

Aside from the "obvious" cases like CORBA support, there is very
little in the Java SE library that I would opt to remove.  The XML
support could use some streamlining, perhaps; it's gotten overgrown as
Sun has gotten in the habit of declaring the XML library of the week
to be "standard" and adding it.  So I suspect we disagree there, or
are thinking of different definitions of "standard library" (and if
you start including Java EE or other javax.* packages that aren't part
of the Java SE library, I'd certainly agree with you).

Library design, as ever, is a series of rather hard tradeoffs. :)

> > (And that doesn't even get into operators like ++ and +=3D; I'd probably=

> > prefer to have +=3D, at least, implemented automatically in terms of +
> > instead of being its own operator, but it's not a clear choice.)
>
> There are times when being able to override +=3D would be useful, because
> using + to synthesise it involves throwing away an object, and if they're
> heavyweight, that's not great. If your objects are million-by-million
> matrices, for instance, you'd really like to be able to add in place.

If your objects are million-by-million matrices, I would hope that you
have some kind of sparse matrix structure, or some other compositional
representation that doesn't actually hold all trillion elements in
memory simultaneously.  Large isn't *necessarily* slow, if you're
clever.

> One thing we definitely shouldn't have is overriding of the =3D operator,
> as C++ lets you do. That's just insane. Ditto the . operator.

No argument from me.  The . and =3D operators only make sense in C++
because C++ has objects-as-values.  I'd add -> to the list (even
though the Java equivalent is .), since object indirection is a fairly
core part of the language and I don't want anyone monkeying with it.

> > As others have already suggested, a solution like
>
> > public interface Addable<A, S> {
> > =A0public S add (A addend);
> > }
>
> > with generic "S"um and "A"ddend types makes the most sense. =A0It's
> > just, like so much in Java, unpleasantly verbose in the simple case --
> > a number-like class (for example, BigDecimal) would become
>
> > public class BigDecimal implements Addable<BigDecimal, BigDecimal>,
> > Comparable<BigDecimal>, ...;
>
> > That's a lot of "BigDecimal"s.
>
> A bit of syntactic sugar which let 'this' stand for the current declaring
> class might help.
>
> > And since BD is not final, most of those generic types might have to be
> > ? extends BigDecimal.
>
> Urgh, is that how generics work? I'm not very au fait with them.

It Depends On What You Want.  If, eg., BigDecimal implements
Comparable<BigDecimal> (which it does), and you subclass BigDecimal as
MyBigDecimal (which you can), then you wind up with MyBigDecimal
implementing Comparable<BigDecimal>, which is actually what you want
(as it allows clients to compare objects of your subclass to arbitrary
BigDecimal objects).

I hadn't thought through the implications completely when I wrote
that, hence the "might"; now that I have time to sit and play with it
a bit I think they could just be <BigDecimal> type constraints and the
semantics would come out okay.

> Also, can i declare:
>
> public class Vector implements Multipliable<double, Vector>,
> Multipliable<Vector, double>, Multipliable<Matrix, Vector>
>
> ?

No, as double is not a reference type; no, as you can't implement an
interface more than once and all those generic specializations are
really the same interface.  The former can be worked around with the
language as-is; the latter cannot.  Allowing that would involve
changing the way method overloads are resolved, or adding rules to
forbid implementing both Multipliable<Double, Vector> and
Multipliable<Vector, Vector> - as it stands, you can't provide both
public Double multiply (Vector) and public Vector multiply (Vector) in
the same class, because the only distinction is the return type.

> --
> [The sig that ate Manhattan...]

Jesus H!  McQuary limit, anyone?

On 9 Mag, 02:02, "Daniel Dyer" <"You don't need it"> wrote:
> On Fri, 09 May 2008 00:48:48 +0100, Tom Anderson <t...@urchin.earth.li> =
=A0
> wrote:
>
>
>
>
>
> > On Thu, 8 May 2008, Roedy Green wrote:
>
> >> On Thu, 8 May 2008 04:47:53 -0700 (PDT), josh <xdevel1...@gmail.com>
> >> wrote, quoted or indirectly quoted someone who said :
>
> >>> I don't find any document that say if the operator overloading will be=

> >>> a new feature of the Java 7
>
> >> Usually when the matter comes up, there is a quite a squawk of "over
> >> my dead bodies".
>
> >> My view is user defined operators with new names/symbols would be =A0
> >> acceptable, but overloading ordinary >> to do I/O is as C++ is an =A0
> >> abomination. =A0Unicode has lots of symbols you could use as user-defin=
ed =A0
> >> operators.
>
> > As Patricia pointed out, this doesn't help the rather major case of =A0
> > wanting to do maths on compound types with conventional operators.
>
> > I said it before and i'll say it again: the crimes committed in C++ =A0
> > reflect cultural, not technical, problem. Other languages let you =A0
> > overload << and >>, amongst other things, and haven't seen any abuse at =
=A0
> > all.
>
> The most useful thing Sun could do would be at least to overload the =A0
> arithmetic operators to work with BigDecimal and BigInteger. =A0I believe =
it =A0
> is this that has been proposed for Java 7, rather than general-purpose, =
=A0
> user-defined operator overloading.
>
> Alex Miller maintains a page detailing the current status and latest news =
=A0
> surrounding the various Java 7 proposals:
>
> http://tech.puredanger.com/java7/
>
> Dan.
>
> --
> Daniel Dyerhttp://www.uncommons.org- Nascondi testo tra virgolette -
>
> - Mostra testo tra virgolette -

Thanks for the answer I simply would know news about proposal.

However, in my opinion, I think that a language must offer many
possiblilty
to do thinks and must be much more rich of features...

Java I think should implements advanced constructions (closures,
operator overloading, lambda expression, pointer functions and so on)
and after a programmer can choose if using or not.

Is not goog having few features.

Java is a clean and an advanced language but in this last years it's
loosing in flexibility
against, for examples, C# that is at the moment better that it.

In fact it seems that Java is running to reach it. In past it was the
opposite!!!!

At the end, yes I know, we can always to use the immortal C++...but
why?

I want to use Java and I want that the developers offer me as many
features as the programmers want so they can be more productive.

Regards

Stefan Ram wrote:

> Supersedes: <plus-20080508173952@ram.dialup.fu-berlin.de>
> 
> Tom Anderson <twic@urchin.earth.li> quotes:
>>>>Time t3 = t + t2;
> 
>   From a person who is not a native speaker of English:
>   Is this pronounced »T plus T two«, »T add T two«,
>   or in yet another way?

The former, T plus T2.

> 
>   If the previous sum was not pronounced using »add«, 
>   why is »add« often used in expressions like
> 
> t.add( t2 )
> 
>   instead of the word pronounced for the operator above?

"plus" is the common name of the operator symbol, the operation is actually
addition and the verb is "to add". The method is named (more correctly) after
the verb rather than the common name of the operator representing the
operation. However, in common usage we say "plus" and the code would read more
easily if the method were named "plus" [provided you knew that "plus" stood for
addition].

The same also applies to "minus" (subtraction) and "times" (multiplication).
Division is the odd one out.

-- 
Nigel Wade

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-1313695486-1210327342=:25495
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <Pine.LNX.4.64.0805091102251.25495@urchin.earth.li>

On Thu, 8 May 2008, Owen Jacobson wrote:

> On May 8, 8:10�pm, Tom Anderson <t...@urchin.earth.li> wrote:
>> On Thu, 8 May 2008, Owen Jacobson wrote:
>>> On May 8, 1:52�pm, Tom Anderson <t...@urchin.earth.li> wrote:
>>>
>>>> You could even model a little hierarchy on discrete mathematics: Addable,
>>>> Multipliable, Ring extends Addable, Multipliable, Dividable, Field extends
>>>> Ring, Dividable, etc.
>>
>>> The question is, at the language and standard library level, do you
>>> provide four interfaces (for +, *, /, and -) or one (for all four) or
>>> five (both) or some other combination?
>
> It's worth looking at the way Haskell handles operator overloading and
> numeric types here. [SNIP]

Thanks for that. It sounds a bit like Smalltalk's hierarchy, only a bit 
more rigorously thought out.

>>> If you include every possible combination of operators in the standard
>>> library, you end up with a huge number of mostly-useless interfaces.
>>
>> Which is a pretty fair description of the standard library at present!
>
> You've a call from the org.omg package complaining about unfair
> representation.  ;)
>
> Aside from the "obvious" cases like CORBA support, there is very little 
> in the Java SE library that I would opt to remove.  The XML support 
> could use some streamlining, perhaps; it's gotten overgrown as Sun has 
> gotten in the habit of declaring the XML library of the week to be 
> "standard" and adding it.  So I suspect we disagree there, or are 
> thinking of different definitions of "standard library" (and if you 
> start including Java EE or other javax.* packages that aren't part of 
> the Java SE library, I'd certainly agree with you).

Much or most of the standard library is indeed pretty good. There are 
patches where it's not, though - J2EE, XML, Swing. I often feel like i'm 
jumping through hoops with java.io, but only when trying to mix 
readers/writers and streams.

>>> (And that doesn't even get into operators like ++ and +=; I'd probably
>>> prefer to have +=, at least, implemented automatically in terms of +
>>> instead of being its own operator, but it's not a clear choice.)
>>
>> There are times when being able to override += would be useful, because
>> using + to synthesise it involves throwing away an object, and if they're
>> heavyweight, that's not great. If your objects are million-by-million
>> matrices, for instance, you'd really like to be able to add in place.
>
> If your objects are million-by-million matrices, I would hope that you 
> have some kind of sparse matrix structure, or some other compositional 
> representation that doesn't actually hold all trillion elements in 
> memory simultaneously.

No, i'm doing weather simulations. Or handling terapixel images.

>> One thing we definitely shouldn't have is overriding of the = operator,
>> as C++ lets you do. That's just insane. Ditto the . operator.
>
> No argument from me.  The . and = operators only make sense in C++ 
> because C++ has objects-as-values.

True. There are certainly positive things you can do with this power, but 
it's still, IMHO, too much of a headache.

> I'd add -> to the list (even though the Java equivalent is .), since 
> object indirection is a fairly core part of the language and I don't 
> want anyone monkeying with it.

It's that meaning of . i meant - java's ., which is C++'s ->. Java doesn't 
really have a .. But if it did, i would want it to be overridable!

That said, python lets you override ., and it can actually be very useful 
at times (making proxy objects and things like that). Without python's 
dynamicity, it would be less useful, so i'm happy to leave it out of java.

>>> As others have already suggested, a solution like
>>
>>> public interface Addable<A, S> {
>>> �public S add (A addend);
>>> }
>>
>>> with generic "S"um and "A"ddend types makes the most sense. �It's
>>> just, like so much in Java, unpleasantly verbose in the simple case --
>>> a number-like class (for example, BigDecimal) would become
>>
>>> public class BigDecimal implements Addable<BigDecimal, BigDecimal>,
>>> Comparable<BigDecimal>, ...;
>>
>> Also, can i declare:
>>
>> public class Vector implements Multipliable<double, Vector>,
>> Multipliable<Vector, double>, Multipliable<Matrix, Vector>
>>
>> ?
>
> No, as double is not a reference type; no, as you can't implement an
> interface more than once and all those generic specializations are
> really the same interface.  The former can be worked around with the
> language as-is; the latter cannot.

In that case, i think any interface-based solution fails.

> Allowing that would involve changing the way method overloads are 
> resolved, or adding rules to forbid implementing both 
> Multipliable<Double, Vector> and Multipliable<Vector, Vector> - as it 
> stands, you can't provide both public Double multiply (Vector) and 
> public Vector multiply (Vector) in the same class, because the only 
> distinction is the return type.

That's fair enough. I can't think of any approach to operator overloading 
that would allow that without further language change. Overloading on 
return type is the kind of thing perl would do.

>> --
>> [The sig that ate Manhattan...]
>
> Jesus H!  McQuary limit, anyone?

Apologies! I mostly have 1-3 line sigs, but i love that quote, and i 
couldn't see any way to trim it down. So, once in a while, i indulge 
myself and impose it on usenet. On average, my sig length is still well 
under the limit, and probably shorter than most (most who have sigs, that 
is).

tom

-- 
Annoying others means you are wise; it is when you annoy yourself that
you are truly enlightened. -- The Bullet Proof Monk
---910079544-1313695486-1210327342=:25495--

josh wrote:
> Java I think should implements advanced constructions (closures,
> operator overloading, lambda expression, pointer functions and so on)
> and after a programmer can choose if using or not.
> 
> Is not good having few features.

You are missing one major point.

Actually writing the code is not a big chunk of
the man power that goes into an application.

Adding new stuff to an already written application
(often written by someone else)
as well as support
can be much more resource consuming.

Many of these advanced features you want to use
can make these things much more expensive.

Tom Anderson wrote:
> Much or most of the standard library is indeed pretty good. There are 
> patches where it's not, though - J2EE, XML, Swing. I often feel like i'm 

Those are three areas where Java libraries really shine, actually.

> jumping through hoops with java.io, but only when trying to mix 
> readers/writers and streams.

java.io is pretty straightforward.  What troubles does it cause you?

Normally one would want to avoid mixing Readers/Writers with Streams.  The 
secret to getting them to work together is encoding.  One can hardly blame the 
Java API for dealing with such a complex matter and (oh, horror) letting some 
of that complexity be visible to the programmer.

-- 
Lew

Thomas Schodt wrote:
> josh wrote:
>> Java I think should implements advanced constructions (closures,
>> operator overloading, lambda expression, pointer functions and so on)
>> and after a programmer can choose if using or not.
>>
>> Is not good having few features.
> 
> You are missing one major point.
> 
> Actually writing the code is not a big chunk of
> the man power that goes into an application.
> 
> Adding new stuff to an already written application
> (often written by someone else)
> as well as support
> can be much more resource consuming.
> 
> Many of these advanced features you want to use
> can make these things much more expensive.

Amen.  Code readability and maintainability is far more important than its 
writability.  All those things that josh wants would diminish Java's 
usefulness in the pragmatic world that it has conquered.

-- 
Lew

Thomas Schodt wrote:
> josh wrote:
>> Java I think should implements advanced constructions (closures,
>> operator overloading, lambda expression, pointer functions and so on)
>> and after a programmer can choose if using or not.
>>
>> Is not good having few features.
> 
> You are missing one major point.
> 
> Actually writing the code is not a big chunk of
> the man power that goes into an application.
> 
> Adding new stuff to an already written application
> (often written by someone else)
> as well as support
> can be much more resource consuming.
> 
> Many of these advanced features you want to use
> can make these things much more expensive.

I think that providing infix arithmetic operators to represent
operations on arithmetic types, such as BigDecimal, would make code
using them more readable, which tends reduce maintenance costs.

Patricia

On Fri, 9 May 2008, Thomas Schodt wrote:

> josh wrote:
>
>> Java I think should implements advanced constructions (closures, 
>> operator overloading, lambda expression, pointer functions and so on) 
>> and after a programmer can choose if using or not.
>> 
>> Is not good having few features.
>
> You are missing one major point.
>
> Actually writing the code is not a big chunk of the man power that goes 
> into an application.
>
> Adding new stuff to an already written application (often written by 
> someone else) as well as support can be much more resource consuming.
>
> Many of these advanced features you want to use can make these things 
> much more expensive.

Overloaded operators are not hard to understand. They're just methods with 
unusual names. There is simply nothing strange about them.

tom

-- 
I could tell you a great many more particulars but suppose that you are
tired of it by this time. -- John Backhouse, Trainspotter Zero

Owen Jacobson wrote:
> On May 8, 8:10 pm, Tom Anderson <t...@urchin.earth.li> wrote:
>> Also, can i declare:
>>
>> public class Vector implements Multipliable<double, Vector>,
>> Multipliable<Vector, double>, Multipliable<Matrix, Vector>
>>
>> ?
> 
> No, as double is not a reference type; no, as you can't implement an
> interface more than once and all those generic specializations are
> really the same interface.  The former can be worked around with the
> language as-is; the latter cannot.  Allowing that would involve
> changing the way method overloads are resolved, or adding rules to
> forbid implementing both Multipliable<Double, Vector> and
> Multipliable<Vector, Vector> - as it stands, you can't provide both
> public Double multiply (Vector) and public Vector multiply (Vector) in
> the same class, because the only distinction is the return type.

Multipliable<Double, Vector> would essentially provide the same service 
as Multipliable<double, Vector> thanks to auto-(un)boxing.

Also (as the one who posted with this proposal), the idea of LHS 
operator overloading cannot be satisfactorily be solved in this manner; 
I've been racking my brains for a solution and have found known (more 
discussion in my earlier thread 'Java 7 Features').

This would be Tom's proposed declaration (I believe he munged the 
syntax), then:

public class Vector implements Multipliable<Double, Vector> {
}

public class Matrix implements Multipliable<Double, Matrix>,
     Multipliable<Matrix, Matrix>, Multipliable<Vector, Vector> {
}

Unfortunately, to do so would still require modification such that a 
class can implement the same generic interface multiple times with 
different generic arguments--i.e., reification of generics.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Daniel Dyer wrote:
> Alex Miller maintains a page detailing the current status and latest 
> news surrounding the various Java 7 proposals:
> 
> http://tech.puredanger.com/java7/

Thanks for the link, it's the one I alluded to in a previous post!

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On Fri, 9 May 2008, Lew wrote:

> Tom Anderson wrote:
>
>> Much or most of the standard library is indeed pretty good. There are 
>> patches where it's not, though - J2EE, XML, Swing. I often feel like i'm 
>
> Those are three areas where Java libraries really shine, actually.

No.

>> jumping through hoops with java.io, but only when trying to mix 
>> readers/writers and streams.
>
> java.io is pretty straightforward.  What troubles does it cause you?
>
> Normally one would want to avoid mixing Readers/Writers with Streams. 
> The secret to getting them to work together is encoding.  One can hardly 
> blame the Java API for dealing with such a complex matter and (oh, 
> horror) letting some of that complexity be visible to the programmer.

I'm not convinced it does it in the best way possible.

I think i was doing something where i needed to be able to read lines of 
text, but also things in binary, from a stream. To read lines, you need a 
BufferedReader, and to read binary data, you need a DataInputStream; you 
can wrap the BufferedReader round an InputStreamReader, and wrap that 
round the DataInputStream, or whatever stream underlies that. But then you 
have a problem, because the BufferedReader is eating more the data than it 
should. DataInputStream has a readLine of its own, but it'd deprecated and 
doesn't do character encoding.

More generally, i just don't see why there needs to be a Reader/Writer 
hierarchy that parallels the InputStream/OutputStream hierarchy. Why not 
just have a Reader, which wraps an InputStream and does decoding, and a 
Writer, which wraps an OutputStream and does encoding? The Reader would be 
able to read lines, but only if on top of a PushbackInputStream. That 
would have solved my problem in a trice.

I guess there's a case for StringReader/StringWriter too. But not the 
File/Buffered/whatever ones. Byte streams can provide those facilities.

tom

-- 
Heinlein has done more to harm SF than has any other writer, I think. --
PKD

Tom Anderson wrote:
> I think i was doing something where i needed to be able to read lines of 
> text, but also things in binary, from a stream. To read lines, you need 
> a BufferedReader, and to read binary data, you need a DataInputStream; 
> you can wrap the BufferedReader round an InputStreamReader, and wrap 
> that round the DataInputStream, or whatever stream underlies that. But 
> then you have a problem, because the BufferedReader is eating more the 
> data than it should. DataInputStream has a readLine of its own, but it'd 
> deprecated and doesn't do character encoding.
> 
> More generally, i just don't see why there needs to be a Reader/Writer 
> hierarchy that parallels the InputStream/OutputStream hierarchy. Why not 
> just have a Reader, which wraps an InputStream and does decoding, and a 
> Writer, which wraps an OutputStream and does encoding? The Reader would 
> be able to read lines, but only if on top of a PushbackInputStream. That 
> would have solved my problem in a trice.
> 
> I guess there's a case for StringReader/StringWriter too. But not the 
> File/Buffered/whatever ones. Byte streams can provide those facilities.

The problem is that what you're asking for covers only a handful of 
cases: those in which binary data gets mixed with LF-terminated (or CRLF 
or CR) string data. It does not cover cases where the string data is 
embedded in the binary data, which is far more common in the real world. 
The normal way to handle it is:

    final DataInputStream dis = new DataInputStream(...);
    final CharSet cs = CharSet.forName("ISO-8859-1");
    final byte[] ba = new byte[32];
       ...
    for (;;) {
          ...
       dis.readFully(ba);
       final String st = new String(ba, cs);
          ...
    }

or, for variable-length strings, probably something like:

    for (;;) {
          ...
       final short l = dis.readShort();
       final byte[] ba = new byte[l];
       dis.readFully(ba);
       final String st = new String(ba, cs);
          ...
    }



(Exception: if your file is /only/ to be read and written by Java, the 
WriteUTF and ReadUTF may be appropriate.)
-- 
John W. Kennedy
  "You can, if you wish, class all science-fiction together; but it is 
about as perceptive as classing the works of Ballantyne, Conrad and W. 
W. Jacobs together as the 'sea-story' and then criticizing _that_."
   -- C. S. Lewis.  "An Experiment in Criticism"

Owen Jacobson wrote:

> It might be instructive to think about how foreach was made
> extensible: there is an interface which, if implemented properly, can
> make an arbitrary class usable in a for(each) loop.  The same could be
> done to map syntax to operations:

> However, it's not clear whether the core operators (+, *, /, binary -,
> unary -, ++, --) should be exposed as a single interface (Arithmetic),
> several interfaces (Addable, Multipliable, Dividable/Rational, etc).

I wonder too if it might be better to allow *new* operators, rather than 
change existing ones.

class Matrix {

   public Matrix add( Matrix m )
   {
    //...
   }
  //...
}

has to be invoked like this:

   Matrix x = y.add( z );

but what if you could call it like this:

   Matrix x = y .add. z;

?

Just allow a more algebraic notation with method names as a convenience 
for those who need it.

   Matrix a = ( .negate. s ) .multiply. z;

Hmm, unary negation bothers me... nothing on the left side... maybe it 
would be assumed that s has a parameterless method with the same name in 
that case?  Same as

   Matrix a = ( s.negate() ).multiply( z );

I'm not sure, I'm not one of the advocates for operator overloading in 
Java....

josh wrote:
> Hi,
> 
> I don't find any document that say if the operator overloading will be
> a new feature of the Java 7
> 
> Do anyone know if it there will be?
> 
> Thanks

It looks like BigNum might be allowed to use operators next....

http://tech.puredanger.com/java7/

In article <ig9Vj.3312$nl7.1098@flpi146.ffdc.sbc.com>,
 Mark Space <markspace@sbc.global.net> wrote:

> josh wrote:
> > Hi,
> > 
> > I don't find any document that say if the operator overloading will be
> > a new feature of the Java 7
> > 
> > Do anyone know if it there will be?
> > 
> > Thanks
> 
> It looks like BigNum might be allowed to use operators next....
> 
> http://tech.puredanger.com/java7/

I'd love to see it in general.  I know it leads to some wild abuses in 
C++, but it is also extremely powerful in making some common operations 
simpler.  It's not fair that only String can do it :)

-- 
Block Google's spam and enjoy Usenet again.
Reply with Google and I won't hear from you.

Mark Space wrote:
> I'm not sure, I'm not one of the advocates for operator overloading in 
> Java....

How remarkable that you would brainstorm for a viable syntax for doing so, then.

Reasons for or against operator overloading, as with so many language features 
current or proposed, tend to emanate from those with opinions already on the 
matter rather than to inform such opinions.

It is refreshing and perhaps revolutionary that the users of a programming 
language should even imagine they have a voice in the specification of that 
language, let alone that we actually do.  It is arguably historic.

-- 
Lew

Tom Anderson wrote:
> Overloaded operators are not hard to understand. They're just methods 
> with unusual names. There is simply nothing strange about them.

Absolutely.

Until someone overloads an operator
with something
that does not do what one would expect,
or potentially even worse;
seems to do what one would expect
but has some hidden side-effects.

With named methods
people are more likely to make up a new name
that better describes what the method does.

On Fri, 9 May 2008, Mark Space wrote:

> Owen Jacobson wrote:
>
>> However, it's not clear whether the core operators (+, *, /, binary -, 
>> unary -, ++, --) should be exposed as a single interface (Arithmetic), 
>> several interfaces (Addable, Multipliable, Dividable/Rational, etc).
>
> I wonder too if it might be better to allow *new* operators, rather than 
> change existing ones.
>
> class Matrix {
>
>  public Matrix add( Matrix m )
>  {
>   //...
>  }
> //...
> }
>
> has to be invoked like this:
>
>  Matrix x = y.add( z );
>
> but what if you could call it like this:
>
>  Matrix x = y .add. z;
>
> ?

Mark, 1957 just called, FORTRAN wants its operators back.

Only kidding. I quite like this idea of a general notation for infix 
methods. But ...

> Just allow a more algebraic notation with method names as a convenience for 
> those who need it.
>
>  Matrix a = ( .negate. s ) .multiply. z;

It still doesn't really make maths pleasant to write.

> Hmm, unary negation bothers me... nothing on the left side... maybe it would 
> be assumed that s has a parameterless method with the same name in that case? 
> Same as
>
>  Matrix a = ( s.negate() ).multiply( z );

Yes. I don't see a problem with this.

tom

-- 
Finals make a man mean; let's fusc up and write!

On Sat, 10 May 2008, Thomas Schodt wrote:

> Tom Anderson wrote:
>
>> Overloaded operators are not hard to understand. They're just methods 
>> with unusual names. There is simply nothing strange about them.
>
> Absolutely.
>
> Until someone overloads an operator with something that does not do what 
> one would expect, or potentially even worse; seems to do what one would 
> expect but has some hidden side-effects.

True.

> With named methods people are more likely to make up a new name that 
> better describes what the method does.

I see absolutely no reason to believe that to be the case.

tom

-- 
Finals make a man mean; let's fusc up and write!

"Tom Anderson" <twic@urchin.earth.li> wrote in message 
news:Pine.LNX.4.64.0805101425180.24915@urchin.earth.li...
> On Fri, 9 May 2008, Mark Space wrote:
>
>> Owen Jacobson wrote:
>>
>>> However, it's not clear whether the core operators (+, *, /, binary -, 
>>> unary -, ++, --) should be exposed as a single interface (Arithmetic), 
>>> several interfaces (Addable, Multipliable, Dividable/Rational, etc).
>>
>> I wonder too if it might be better to allow *new* operators, rather than 
>> change existing ones.
>>
>> class Matrix {
>>
>>  public Matrix add( Matrix m )
>>  {
>>   //...
>>  }
>> //...
>> }
>>
>> has to be invoked like this:
>>
>>  Matrix x = y.add( z );
>>
>> but what if you could call it like this:
>>
>>  Matrix x = y .add. z;
>>
>> ?
>
> Mark, 1957 just called, FORTRAN wants its operators back.
>
> Only kidding. I quite like this idea of a general notation for infix 
> methods. But ...
[ SNIP ]

In Haskell you can use a binary function infix, by enclosing it with 
backticks. E.g.

> let dot x y = sum $ zipWith (*) x y
> let a = [1,3,-5]
> let b = [4,-2,-1]
> dot a b
3
> a `dot` b
3

Similarly, operators (which are functions consisting entirely of 
non-alphanumeric characters), normally used infix, can be used prefix. But 
this is all syntactic sugar - some binary functions are easier to read 
infix.

As far as Java goes I am now so used to

Matrix x = y.add(z)

that I automatically read it as "add z to y and return x". I'd find a new 
syntax a bit jarring myself.

AHS 

"Tom Anderson" <twic@urchin.earth.li> wrote in message 
news:Pine.LNX.4.64.0805101428000.24915@urchin.earth.li...
> On Sat, 10 May 2008, Thomas Schodt wrote:
>
[ SNIP ]
>> With named methods people are more likely to make up a new name that 
>> better describes what the method does.
>
> I see absolutely no reason to believe that to be the case.
>
> tom

Nor do I - it depends entirely on the programmer.

As one example, does "printf" in Java 1.5+ PrintStream better describe what 
it does than, say, "print" or "println"? No - it has one cryptic little 'f' 
in the function name that makes sense to people who have programmed in C, 
but sure as hell doesn't mean anything to lots and lots of Java programmers 
these days...not until they read the API docs.

One of my favourite method names is "processFile". Just Google on it... :-) 
I have been guilty of using it myself. What exactly does this tell you, 
apart from the fact that a file is being...ummm..."processed"? Although if 
the processing consists of deleting the file people are generally helpful 
enough to say "delete" (or something similar).

AHS

Mark Space wrote:
....
> I wonder too if it might be better to allow *new* operators, rather than 
> change existing ones.
> 
> class Matrix {
> 
>   public Matrix add( Matrix m )
>   {
>    //...
>   }
>  //...
> }
> 
> has to be invoked like this:
> 
>   Matrix x = y.add( z );
> 
> but what if you could call it like this:
> 
>   Matrix x = y .add. z;
....

This would create some parsing problems. Currently, the compiler can
tell whether "y .add" is a method call or a field reference by looking
ahead one token to see if "add" is followed by "(". That works even if,
as in this program, y's class has both a method and a field with the
identifier "add".

public class Matrix {
   Sub add = new Sub();
   public static void main(String[] args) {
     Matrix x = new Matrix();
     System.out.println(x .add. y);
   }
   public Matrix add(Matrix x){
     return null;
   }
   private static class Sub{
     private Matrix y = null;
   }
}

Although this syntax is better than the current prefix method call
syntax, I don't think it is enough to make a Java Complex class usable
for some of the expressions I've seen in scientific and engineering
Fortran programs.

Patricia

Arved Sandstrom wrote:
....
> As far as Java goes I am now so used to
> 
> Matrix x = y.add(z)
> 
> that I automatically read it as "add z to y and return x". I'd find a new 
> syntax a bit jarring myself.

I don't think isolated operations make the case for overloading. They
seem just as readable to me in prefix method call as with arithmetic
operators. We really need to think about expressions with multiple terms
and operators.

Here is a *very* simple example, with only half a dozen operations.
Consider calculating the sum of the first n terms of an arithmetic
series, given its first term, a1, and common difference, d.
http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29

Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
This version is a very simple transformation of the mathematical notation.

Anyone up to writing this out in prefix method call notation?

Patricia

Patricia Shanahan wrote:

> 
> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
> This version is a very simple transformation of the mathematical notation.
> 
> Anyone up to writing this out in prefix method call notation?

n.minus(1).times(d).plus(a1.times(2)).times(n).dividedBy(2)

But yes it's hard to recognize it as the same function, even if I have 
it correct.

Hmmm...

( n .times. ( (2 .times. a1) .plus. ( n .minus. 1) .times. d))

..dividedBy. 2;


I'm still not sure this is better.  Just thinking out loud...

Also... m.times.n  ... is that m * n, or an access to a public field 
"times.n" inside m.  Ouch...

Tom Anderson wrote:

>>  Matrix x = y .add. z;
>>
>> ?
> 
> Mark, 1957 just called, FORTRAN wants its operators back.
> 


I new I'd seen those somewhere before.  Thanks!


Fortran ... was ...


.... so ...


.... long ... ago ...
















.... Jim!

Mark Space wrote:
> Tom Anderson wrote:
>>>  Matrix x = y .add. z;
>>>
>>> ?
>>
>> Mark, 1957 just called, FORTRAN wants its operators back.
> 
> I new I'd seen those somewhere before.  Thanks!

Actually Fortran only used that form for comparison
operators.

Arne

Patricia Shanahan <pats@acm.org> writes:
>Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
>This version is a very simple transformation of the mathematical notation.
>Anyone up to writing this out in prefix method call notation?

  On can always use a program to transform an infix expression like

BigDecimal( "2" )+ BigDecimal( "3" )* BigDecimal( "4" )

  to a prefix expression like

( new java.math.BigDecimal( "2" ) ).add( ( new java.math.BigDecimal( "3" ) ).multiply( new java.math.BigDecimal( "4" ) ) )

  with a program like

#include <string>
#include <iostream>
#include <ostream>

class BigDecimal;

::std::ostream& operator<<( ::std::ostream& os, const BigDecimal& number );

class BigDecimal
{ ::std::string const value_;
  BigDecimal const * const left_;
  BigDecimal const * const right_;

  public:

  explicit BigDecimal( ::std::string const value ): 
  value_( value ), left_( 0 ), right_( 0 ){}

  explicit BigDecimal
  ( ::std::string const op, 
    BigDecimal const * const left, 
    BigDecimal const * const right ): 
  value_( op ), left_( left ), right_( right ){}

  ::std::ostream& Print( ::std::ostream& os ) const
  { if( value_ == "+" )
    return  os << "( " << *left_ << " ).add( " << *right_ << " )";
    else if( value_ == "*" )
    return os << "( " << *left_ << " ).multiply( " << *right_ << " )";
    else
    return os << "new java.math.BigDecimal( \"" << value_ << "\" )"; }};

const BigDecimal operator+
( const BigDecimal left, const BigDecimal right )
{ BigDecimal temp( "+", &left, &right );
  return temp; }

const BigDecimal operator*
( const BigDecimal left, const BigDecimal right )
{ BigDecimal temp( "*", &left, &right );
  return temp; }

::std::ostream& operator<<( ::std::ostream& os, const BigDecimal& number )
{ return number.Print( os ); }

int main()
{ ::std::cout << BigDecimal( "2" )+ BigDecimal( "3" )* BigDecimal( "4" )<< '\n'; }

  .

  Disclaimer: I do not use C++ that often, and therefore I am not 
  sure if I got the lifetime of all temporaries right.

Patricia Shanahan wrote:
> Although this syntax is better than the current prefix method call
> syntax, I don't think it is enough to make a Java Complex class usable
> for some of the expressions I've seen in scientific and engineering
> Fortran programs.

For complex it is more important that the operators be exactly the same 
as those used for float and double. This is less valuable for other 
types like matrices and vectors. The reason is that many expressions on 
complex values are exactly the same (and have the same meaning) with the 
complex values replaced by real values.
> 
> Patricia

Stefan Ram wrote:
> Patricia Shanahan <pats@acm.org> writes:
>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
>> This version is a very simple transformation of the mathematical notation.
>> Anyone up to writing this out in prefix method call notation?
> 
>   On can always use a program to transform an infix expression like
> 
> BigDecimal( "2" )+ BigDecimal( "3" )* BigDecimal( "4" )
> 
>   to a prefix expression like
> 
> ( new java.math.BigDecimal( "2" ) ).add( ( new java.math.BigDecimal( "3" ) ).multiply( new java.math.BigDecimal( "4" ) ) )


I was thinking the same thing.  What is going in Java 7 is even more 
support for scripting.  I wonder if that could be used to translate from 
infix to prefix.

import some.package.mathscript;

public class MatUtil {

   public Matrix transform( Matrix a, Matrix b )
   {
     Matrix result;

     @<mathscript>
        result = (-a)*b;
     @</mathscript>

     return result;
   }
}


Looks a bit like JSP.  Hmm, I wonder if that's a good thing.  The need 
to make your own scripting engine should prevent the most cavalier abuse 
of this type of construct, I think.


P.S. Does anyone else get surprised when their mail client doesn't 
auto-indent? I always am.

On Sat, 10 May 2008 20:01:42 +0100, Mark Space <markspace@sbc.global.net>  
wrote:

> Stefan Ram wrote:
>> Patricia Shanahan <pats@acm.org> writes:
>>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
>>> This version is a very simple transformation of the mathematical  
>>> notation.
>>> Anyone up to writing this out in prefix method call notation?
>>    On can always use a program to transform an infix expression like
>>  BigDecimal( "2" )+ BigDecimal( "3" )* BigDecimal( "4" )
>>    to a prefix expression like
>>  ( new java.math.BigDecimal( "2" ) ).add( ( new  
>> java.math.BigDecimal( "3" ) ).multiply( new java.math.BigDecimal( "4" )  
>> ) )
>
>
> I was thinking the same thing.  What is going in Java 7 is even more  
> support for scripting.  I wonder if that could be used to translate from  
> infix to prefix.

One option is to use Groovy.  It uses BigDecimal by default for numeric  
literals:

http://groovy.codehaus.org/Groovy+Math

Dan.

-- 
Daniel Dyer
http://www.uncommons.org

Daniel Dyer wrote:
>> I was thinking the same thing.  What is going in Java 7 is even more 
>> support for scripting.  I wonder if that could be used to translate 
>> from infix to prefix.
> 
> One option is to use Groovy.  It uses BigDecimal by default for numeric 
> literals:
> 
> http://groovy.codehaus.org/Groovy+Math
> 
> Dan.
> 

Unfortunately performance is terrible. Not exactly suitable for serious 
maths.

Mark Thornton

Mark Thornton <mthornton@optrak.co.uk> writes:
>Unfortunately performance is terrible. Not exactly suitable for
>serious maths.

  Another possibility would be an IDE that can display certain
  Java prefix expression as an infix expression in an edit box.

  It knows about BigDecimal and can learn about the operators
  and precedence rules for other classes from annotations.

  This has been done before: Some word processors have an
  internal language for mathematical terms and contain WYSIWYG
  formula editors for them.

Patricia Shanahan wrote:
> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
> This version is a very simple transformation of the mathematical notation.
> 
> Anyone up to writing this out in prefix method call notation?

/ * n + * 2 a1 * - n 1 d 2

result =
   divide( multiply( n,
                     add( multiply( 2, a1 ),
                          multiply( subtract( n, 1 ),
                                    d ),
           2 );

I cheated.  I used static methods.

-- 
Lew

Patricia Shanahan wrote:
>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
>> This version is a very simple transformation of the mathematical 
>> notation.
>>
>> Anyone up to writing this out in prefix method call notation?

Mark Space wrote:
> n.minus(1).times(d).plus(a1.times(2)).times(n).dividedBy(2)
   ^                                           ^
This might break down if the methods mutate n; not if if they create new 
objects for the results.

-- 
Lew

Mark Space wrote:
....
> import some.package.mathscript;
> 
> public class MatUtil {
> 
>   public Matrix transform( Matrix a, Matrix b )
>   {
>     Matrix result;
> 
>     @<mathscript>
>        result = (-a)*b;
>     @</mathscript>
> 
>     return result;
>   }
> }
> 
> 
> Looks a bit like JSP.  Hmm, I wonder if that's a good thing.  The need 
> to make your own scripting engine should prevent the most cavalier abuse 
> of this type of construct, I think.
....

What forms of abuse does this prevent that would not also be prevented
by mapping e.g. a+b to a.add(b)?

Patricia

Arne Vajh�j wrote:
> Mark Space wrote:
>> Tom Anderson wrote:
>>>>  Matrix x = y .add. z;
>>>>
>>>> ?
>>>
>>> Mark, 1957 just called, FORTRAN wants its operators back.
>>
>> I new I'd seen those somewhere before.  Thanks!
> 
> Actually Fortran only used that form for comparison
> operators.

and it was relatively harmless in Fortran because the only uses of "."
were inside Hollarith constants and in real and double literals. Also,
Fortran was a hopeless case for single token lookahead parsing.

Patricia

Patricia Shanahan wrote:

> 
> What forms of abuse does this prevent that would not also be prevented
> by mapping e.g. a+b to a.add(b)?
> 
> Patricia

I'm thinking "lazy people."  People who think that typing is a lot of 
work and anything at all that can be done to cut down on programmer 
typing (as opposed to the maintainer's effort) is a good thing.  Or at 
least it's kewl.

So any class that has an "add" method will get overloaded versions of + 
just in the name of kewl.

   List myList = new List();
   myList + "List Item 1";

instead of

  myList.add( "List Item 1" );


Then they'll overload - for remove() because if one is kewl then two are 
even kewler.  And they'll overload ^ for contains() and % for toArray() 
and that'll be sooperkewl.  And then someone will overload << for 
toString() because some *other* language they saw on the *internet* has 
it and then it'll all have gone to s--t.

And I mean individual programmers will sub-class existing (API) classes, 
and writing their own classes.  I'm sure Sun would never stoop to this. 
  But there's a lot of really, really lazy programmers out there, and I 
don't mean that in a good "laziness is a virtue" way.


Some one else on this thread said that the Java community was composed 
of traumatized C++ programmers.  And say that's a good thing.  I like to 
learn from my mistakes, not repeat them.

Mark Space wrote:
....
> And I mean individual programmers will sub-class existing (API) classes, 
> and writing their own classes.  I'm sure Sun would never stoop to this. 
>  But there's a lot of really, really lazy programmers out there, and I 
> don't mean that in a good "laziness is a virtue" way.
....

Sun stooped to the misuse of "+" for String concatenation. I think it
should be reserved for addition.

Patricia

Tom Anderson wrote:
> On Fri, 9 May 2008, Mark Space wrote:
>> ...but what if you could call it like this:
>>
>>  Matrix x = y .add. z;
>>
>> ?
> 
> Mark, 1957 just called, FORTRAN wants its operators back.

1962, actually. Logical operators first appeared in FORTRAN IV.
-- 
John W. Kennedy
  "Information is light. Information, in itself, about anything, is light."
   -- Tom Stoppard. "Night and Day"

John W Kennedy wrote:
> Tom Anderson wrote:
>> On Fri, 9 May 2008, Mark Space wrote:
>>> ...but what if you could call it like this:
>>>
>>>  Matrix x = y .add. z;
>>>
>>> ?
>>
>> Mark, 1957 just called, FORTRAN wants its operators back.
> 
> 1962, actually. Logical operators first appeared in FORTRAN IV.

This is before I was born, but I find it difficult to see how
they could use Fortran for much without .eq., .ne. etc..

Arne

Stefan Ram wrote:
> Mark Thornton <mthornton@optrak.co.uk> writes:
>> Unfortunately performance is terrible. Not exactly suitable for
>> serious maths.
> 
>   Another possibility would be an IDE that can display certain
>   Java prefix expression as an infix expression in an edit box.
> 
>   It knows about BigDecimal and can learn about the operators
>   and precedence rules for other classes from annotations.
> 
>   This has been done before: Some word processors have an
>   internal language for mathematical terms and contain WYSIWYG
>   formula editors for them.
> 

It has been suggested many times. One concern is that without the 
special IDE the resulting code may be unreadable.

Mark Thornton

Arne Vajh�j wrote:
> John W Kennedy wrote:
>> Tom Anderson wrote:
>>> On Fri, 9 May 2008, Mark Space wrote:
>>>> ...but what if you could call it like this:
>>>>
>>>>  Matrix x = y .add. z;
>>>>
>>>> ?
>>>
>>> Mark, 1957 just called, FORTRAN wants its operators back.
>>
>> 1962, actually. Logical operators first appeared in FORTRAN IV.
> 
> This is before I was born, but I find it difficult to see how
> they could use Fortran for much without .eq., .ne. etc..
> 
> Arne
> 

They had an arithmetic if statement (from memory)

if(expr)labelNeg,labelZero,labelPos

The target label depended on the value of the expression. If negative 
the first label was used, zero the second and positive values used the 
third target. All the labels were of course integers.

Mark Thornton

Mark Space <markspace@sbc.global.net> wrote:
> I'm thinking "lazy people."  People who think that typing is a lot of 
> work and anything at all that can be done to cut down on programmer 
> typing (as opposed to the maintainer's effort) is a good thing.  Or at 
> least it's kewl.

Almost correct, except that those people think that their cutting
down on typing effort actually *HELPS* also those who maintain
the code later.

-- 
"Too many notes" a former austrian emperor about some work of W.A.Mozart

Patricia Shanahan <pats@acm.org> writes:
>http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29
>Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.

  The transcription of such term sometimes matters:

      �July 28, 1962 -- Mariner I space probe. A bug in the
      flight software for the Mariner 1 causes the rocket to
      divert from its intended path on launch. Mission control
      destroys the rocket over the Atlantic Ocean. The
      investigation into the accident discovers that a formula
      written on paper in pencil was improperly transcribed into
      computer code�                 ����������������������

http://www.wired.com/software/coolapps/news/2005/11/69355

On Sat, 10 May 2008, Lew wrote:

> Patricia Shanahan wrote:
>>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
>>> This version is a very simple transformation of the mathematical notation.
>>> 
>>> Anyone up to writing this out in prefix method call notation?
>
> Mark Space wrote:
>> n.minus(1).times(d).plus(a1.times(2)).times(n).dividedBy(2)
>  ^                                           ^
> This might break down if the methods mutate n; not if if they create new 
> objects for the results.

Yes. Also, the arithmetic operation would also break if arithmetic 
operators mutate their operands, rather than creating new values.

Personally, i read it as implicit in both cases that they didn't.

tom

-- 
I DO IT WRONG!!!

On Sat, 10 May 2008, John W Kennedy wrote:

> Tom Anderson wrote:
>> On Fri, 9 May 2008, Mark Space wrote:
>>> ...but what if you could call it like this:
>>>
>>>  Matrix x = y .add. z;
>>> 
>>> ?
>> 
>> Mark, 1957 just called, FORTRAN wants its operators back.
>
> 1962, actually. Logical operators first appeared in FORTRAN IV.

Dammit! When i posted that, the back of my mind was saying "ah, but did 
the original fortran have those operators?", but i dismissed it as the 
kind of thing that's unlikely to be the case, and even less likely to get 
caught if it is. Wrongly!

tom

-- 
I DO IT WRONG!!!

On Sat, 10 May 2008, Mark Space wrote:

> Patricia Shanahan wrote:
>
>> What forms of abuse does this prevent that would not also be prevented
>> by mapping e.g. a+b to a.add(b)?
>
> I'm thinking "lazy people."  People who think that typing is a lot of work 
> and anything at all that can be done to cut down on programmer typing (as 
> opposed to the maintainer's effort) is a good thing.  Or at least it's kewl.
>
> So any class that has an "add" method will get overloaded versions of + just 
> in the name of kewl.
>
>  List myList = new List();
>  myList + "List Item 1";
>
> instead of
>
> myList.add( "List Item 1" );
>
> Then they'll overload - for remove() because if one is kewl then two are even 
> kewler.  And they'll overload ^ for contains() and % for toArray() and 
> that'll be sooperkewl.  And then someone will overload << for toString() 
> because some *other* language they saw on the *internet* has it and then 
> it'll all have gone to s--t.

As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN ANY 
LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, not in 
smalltalk, not in ada (that i've heard), not anywhere. Why do you think 
it'll happen in java when it hasn't happened in those languages?

> And I mean individual programmers will sub-class existing (API) classes, and 
> writing their own classes.  I'm sure Sun would never stoop to this.  But 
> there's a lot of really, really lazy programmers out there, and I don't mean 
> that in a good "laziness is a virtue" way.

Do you think that java programmers are, on average, more stupid than 
python, smalltalk or ada programmers?

Actually, i could believe that. Java being the big industrial language 
that every idiot who doesn't fancy a career in McDonald's or Iraq is 
learning, and the others being a bit more niche and sophisticated.

> Some one else on this thread said that the Java community was composed 
> of traumatized C++ programmers.  And say that's a good thing.  I like to 
> learn from my mistakes, not repeat them.

Agreed. So let's learn from our mistakes and use operator overloading 
without abusing it. Not having operator overloading is like giving up cake 
because you once ate so much you were sick - don't give up cake, just 
practice moderation in consuming it. I don't see why we shouldn't have our 
cake and eat it too.

tom

-- 
I DO IT WRONG!!!

Tom Anderson wrote:
> On Sat, 10 May 2008, Lew wrote:
> 
>> Patricia Shanahan wrote:
>>>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
>>>> This version is a very simple transformation of the mathematical 
>>>> notation.
>>>>
>>>> Anyone up to writing this out in prefix method call notation?
>>
>> Mark Space wrote:
>>> n.minus(1).times(d).plus(a1.times(2)).times(n).dividedBy(2)
>>  ^                                           ^
>> This might break down if the methods mutate n; not if if they create 
>> new objects for the results.
> 
> Yes. Also, the arithmetic operation would also break if arithmetic 
> operators mutate their operands, rather than creating new values.
> 
> Personally, i read it as implicit in both cases that they didn't.

In writing my original infix form I certainly intended operators without
side effects. I would expect a "times" method that is intended as a
stand-in for a multiplication operator to behave the same way.

Beyond that, I think the immutable object choice that was made for
BigDecimal, BigInteger, and the primitive wrappers is a good one for
arithmetic objects.

Patricia

Andreas Leitgeb wrote:
> Mark Space <markspace@sbc.global.net> wrote:
>> I'm thinking "lazy people."  People who think that typing is a lot of 
>> work and anything at all that can be done to cut down on programmer 
>> typing (as opposed to the maintainer's effort) is a good thing.  Or at 
>> least it's kewl.
> 
> Almost correct, except that those people think that their cutting
> down on typing effort actually *HELPS* also those who maintain
> the code later.

Really?  I always figured those folks were utterly oblivious to maintenance 
issues, and didn't give it a thought one way or the other, choosing instead to 
focus on their own personal need to shave six keystrokes off of their 
source-code generation.

-- 
Lew

Stefan Ram wrote:
> Patricia Shanahan <pats@acm.org> writes:
>> http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29
>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
> 
>   The transcription of such term sometimes matters:
> 
>       �July 28, 1962 -- Mariner I space probe. A bug in the
>       flight software for the Mariner 1 causes the rocket to
>       divert from its intended path on launch. Mission control
>       destroys the rocket over the Atlantic Ocean. The
>       investigation into the accident discovers that a formula
>       written on paper in pencil was improperly transcribed into
>       computer code�                 ����������������������
> 
> http://www.wired.com/software/coolapps/news/2005/11/69355
> 

I don't think anything is totally error free. I do think that the closer
the computer language form is to the original mathematical formula, the
better the chances of doing the transcription correctly.

Patricia

Andreas Leitgeb wrote:
> "Too many notes" a former austrian emperor about some work of W.A.Mozart

It was not-former (at the time) Holy Roman Empire's (a.k.a. Austria's) Emperor 
Joseph II, referring to Mozart's 1782 composition, /Die Entführung aus dem 
Serail/ (/The Abduction from the Seraglio/), one of Mozart's most enduring and 
popular works and one for which he made no royalties.

Wikipedia cites a suggestion from Conrad Wilson that the actual comment was 
"an extraordinary number of notes".
<http://en.wikipedia.org/wiki/Die_Entf%C3%BChrung_aus_dem_Serail>

At least one source misattributes the quote as a comment about /The Marriage 
of Figaro/.  It also seems that some sources base their assertions on the 
movie /Amadeus/ rather than real life.

-- 
Lew

Tom Anderson wrote:

> As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN ANY 
> LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, not in 
> smalltalk, not in ada (that i've heard), not anywhere. Why do you think 
> it'll happen in java when it hasn't happened in those languages?

I think "disaster hasn't struck yet" is a poor counter argument.  I 
suppose the engineer in me wants to make certain that disaster doesn't 
strike, with a comfortable margin of error.

I like to design things that can't fail, not things that rely on above 
average execution by the user.


> Actually, i could believe that. Java being the big industrial language 
> that every idiot who doesn't fancy a career in McDonald's or Iraq is 

Bingo.  Java is far more popular than Smalltalk, Python, etc.  Masses = 
lower average IQ, even if it's just from time pressure to get projects done.

> learning, and the others being a bit more niche and sophisticated.
> 
>> Some one else on this thread said that the Java community was composed 
>> of traumatized C++ programmers.  And say that's a good thing.  I like 
>> to learn from my mistakes, not repeat them.

I should have said "And I say that's a good thing."  Messed up the 
semantics there.

> 
> Agreed. So let's learn from our mistakes and use operator overloading 
> without abusing it. Not having operator overloading is like giving up 
> cake because you once ate so much you were sick - don't give up cake, 


I'm actually excited to try things besides operator overloading.  Why 
*just* repeat the past?  Why not invent something better?  Think outside 
the box!  The idea of embedding some form of scriptlet, or linking with 
..class files that were generated by a specialized parser, strikes me as 
potentially much more powerful than operator overloading.

Just stuffing Java with every misfeature from past languages does not 
have me excited. I'd like to try a new misfeature.  At least it won't be 
the same old boring misfeature we had be for, it'll be an interesting 
new one. ;)

On Sun, 11 May 2008, Mark Space wrote:

> Tom Anderson wrote:
>
>> As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN ANY 
>> LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, not 
>> in smalltalk, not in ada (that i've heard), not anywhere. Why do you 
>> think it'll happen in java when it hasn't happened in those languages?
>
> I think "disaster hasn't struck yet" is a poor counter argument.

I see. Do tell me about the preparations you've made in case the sun 
doesn't come up tomorrow morning, won't you? And how do you manage to get 
around without ever crossing a road?

> I suppose the engineer in me wants to make certain that disaster doesn't 
> strike, with a comfortable margin of error.
>
> I like to design things that can't fail, not things that rely on above 
> average execution by the user.

Yes, that's definitely a good thing. But there's always a tension between 
being an idiot-proof language and a useful language. In this case, we 
agree (ish) on the usefulness of operator overloading, but disagree on the 
proofness against idiots, and thus on whether operator overloading is a 
good or bad thing.

>> Actually, i could believe that. Java being the big industrial language 
>> that every idiot who doesn't fancy a career in McDonald's or Iraq is 
>> learning, and the others being a bit more niche and sophisticated.
>
> Bingo.  Java is far more popular than Smalltalk, Python, etc.  Masses = lower 
> average IQ, even if it's just from time pressure to get projects done.

I'm not sure the liberal in me is quite ready to believe this. The elitist 
in me certainly isn't ready to give up a useful feature for the good of 
the hoi polloi!

>>> Some one else on this thread said that the Java community was composed of 
>>> traumatized C++ programmers.  And say that's a good thing.  I like to 
>>> learn from my mistakes, not repeat them.
>> 
>> Agreed. So let's learn from our mistakes and use operator overloading 
>> without abusing it. Not having operator overloading is like giving up cake 
>> because you once ate so much you were sick - don't give up cake, 
>
> I'm actually excited to try things besides operator overloading.  Why *just* 
> repeat the past?  Why not invent something better?  Think outside the box! 
> The idea of embedding some form of scriptlet, or linking with .class files 
> that were generated by a specialized parser, strikes me as potentially much 
> more powerful than operator overloading.

....

> Just stuffing Java with every misfeature from past languages does not 
> have me excited. I'd like to try a new misfeature.  At least it won't be 
> the same old boring misfeature we had be for, it'll be an interesting 
> new one. ;)

Ah, i see where you're going with this. Hopefully, this is in a different 
direction to me ...

tom

-- 
I know you wanna try and get away, but it's the hardest thing you'll
ever know

Mark Space wrote:
> Tom Anderson wrote:
> 
>> As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN 
>> ANY LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, 
>> not in smalltalk, not in ada (that i've heard), not anywhere. Why do 
>> you think it'll happen in java when it hasn't happened in those 
>> languages?
> 
> I think "disaster hasn't struck yet" is a poor counter argument.  I 
> suppose the engineer in me wants to make certain that disaster doesn't 
> strike, with a comfortable margin of error.
....

The decision not to do something has its own risks.

Consider the errors that may be made in translating formulas into Java,
or the programs that will be written in Fortran or C++ rather than Java,
because of Java's lack of a reasonable syntax for complex number arithmetic.

Neither having nor not having operator overloading is risk free. The
question, on which reasonable people can disagree, is which carries the
higher cost.

Patricia

Lew <lew@lewscanon.com> wrote:
> Andreas Leitgeb wrote:
>> "Too many notes" a former austrian emperor about some work of W.A.Mozart

> Wikipedia cites a suggestion from Conrad Wilson that the actual comment was 
> "an extraordinary number of notes".

Extraordinarily likely, the original comment was not in english language.
The german version I had in mind was "Zu viele Noten", but that might
indeed just be the version from the movie. I wasn't yet alive when it
was originally said, and neither was any of he Wiki chroniclers ;)

To go back on-Topic:
If there are just more characters needed for a task, than logically
necessary, this doesn't automatically help maintainers.

Having  simple    bi=bi++;  even for a BigInteger is one example that
would save later maintainers much work, compared to the contortions
that are now still needed for BigIntegers.  I wouldn't propose "+" for
anything than scalar arithmetic types.

There, of course, also exist other situations, where Mark's comment 
really applies, and some keystrokes saved by the programmer really
cost multiple on maintenance. (e.g. missing indentation, using only
one-letter field-/method-names)

Mark Space <markspace@sbc.global.net> wrote:
> I think "disaster hasn't struck yet" is a poor counter argument.  I 
> suppose the engineer in me wants to make certain that disaster doesn't 
> strike, with a comfortable margin of error.

I'd like to understand the nature of that "disaster" a bit better.

Is it one of the following list that gives you the creeps?
 1) Someone might overload the operator + to do "-"
      and the other way round, in order to obfuscate (on purpose)
      his code.
 2) Someone might overload operators with actions that 
      not everyone would associate with that operator.
 3) Someone might create a library with such contortions
 4) Sun might add operators for some methods.
      
1) and 2)  are (imo) that "someone"'s own problem. If this 
     "someone" is not writing for his own joy, then he'd have
     to follow some guidelines, anyway.
3) It's quite likely, that not many would really use such a
     library, unless it is brilliant in other parts, but then
     it's unlikely that someone capable to do those other 
     parts would fail so miserably on proper operator-use.
4) Quite unlikely that they defined really grossly unintuitive
     associations.

> I like to design things that can't fail, not things that rely
> on above average execution by the user.

Such a design is usually in itself a failure :-)

If you cannot rely on the users of a prog-language, you (in the
role of a prog-language-designer) should instantly stop designing
any prog-languages.

> I'm actually excited to try things besides operator overloading.
> Why *just* repeat the past?

Because *not everything* in it was bad.

> Why not invent something better?  Think outside 
> the box!  The idea of embedding some form of scriptlet, or linking with 
> .class files that were generated by a specialized parser, strikes me as 
> potentially much more powerful than operator overloading.

Generating new classes for each legible calculation on BigIntegers ?
Strikes me as odd.

> Just stuffing Java with every misfeature from past languages does not 
> have me excited. I'd like to try a new misfeature.  At least it won't be 
> the same old boring misfeature we had be for, it'll be an interesting 
> new one. ;)

Good luck!  I prefer tried and tested "not-all-that-mis"-features.

Tom Anderson <twic@urchin.earth.li> wrote:
> On Sun, 11 May 2008, Mark Space wrote:
>> I think "disaster hasn't struck yet" is a poor counter argument.
> I see. Do tell me about the preparations you've made in case the sun 
> doesn't come up tomorrow morning, won't you?

In this group, one should probably say explicitly, that "sun" refers
to that shiny yellow ball in the sky usually visible on non-cloudy
days, and not just the nickname of some company somehow related to
Java language.

PS: The article "the" before "sun" actually indicates the intended
     meaning, but may be a bit too subtle :-)

Andreas Leitgeb wrote:
> If there are just more characters needed for a task, than logically
> necessary, this doesn't automatically help maintainers.

Also true for having just fewer characters than are needed.  The dicey part is 
knowing what is "needed".

I've seen code where the use of cryptic, extremely short variable names hurt 
readability.  I bet you have to (plural "you").  That shows that it is 
possible to have too few characters in a source line to help maintainers.

-- 
Lew

Andreas Leitgeb wrote:
> Tom Anderson <twic@urchin.earth.li> wrote:
>> On Sun, 11 May 2008, Mark Space wrote:
>>> I think "disaster hasn't struck yet" is a poor counter argument.
>> I see. Do tell me about the preparations you've made in case the sun 
>> doesn't come up tomorrow morning, won't you?
> 
> In this group, one should probably say explicitly, that "sun" refers
> to that shiny yellow ball in the sky usually visible on non-cloudy
> days, and not just the nickname of some company somehow related to
> Java language.
> 
> PS: The article "the" before "sun" actually indicates the intended
>      meaning, but may be a bit too subtle :-)

Normally I'd point to the uncapitalized spelling of "sun" to show the 
difference, but strictly speaking when referring to Sol, "the Sun" is a proper 
noun.

More seriously, I saw absolutely no ambiguity in the use of "sun" in the cited 
passage.  I'm assuming you called out the usage more for humor than for any 
serious advice.

-- 
Lew

Mark Space <markspace@sbc.global.net> wrote:
>> I like to design things that can't fail, not things that rely
>> on above average execution by the user.

Andreas Leitgeb wrote:
> Such a design is usually in itself a failure :-)
> 
> If you cannot rely on the users of a prog-language, you (in the
> role of a prog-language-designer) should instantly stop designing
> any prog-languages.

That is a specious argument.  Those are not the options, nor is it safe to 
"rely on the users of a prog-language".

It is entirely reasonable for a programmer to use any available feature of an 
API.  As an API designer, one absolutely must design the API only to make 
available features intended for use.

Same for the language itself.  You as a Java programmer certainly must 
appreciate all the care Java has built into it to help prevent programmer 
errors.  Features like type safety, runtime exceptions and generics exist for 
the purpose of preventing programmer error.

This has nothing to do with being able to "rely on the users".  It isn't an 
issue of trust in the programmers at all; that's a complete misstatement of 
the issue.  It's a matter of helping the programmer, serving the programmer's 
interest in writing stable, correct code.

Designing a language to ease maintenance and minimize error os a good thing. 
I am incredulous that anyone could even think to assert that "[s]uch a design 
is usually in itself a failure".  How could anyone think that to design 
against failure is "itself a failure"?  That's nonsense.

-- 
Lew

"Lew" <lew@lewscanon.com> wrote in message 
news:acKdnTADa6myqrXVnZ2dnUVZ_qHinZ2d@comcast.com...
> Andreas Leitgeb wrote:
>> If there are just more characters needed for a task, than logically
>> necessary, this doesn't automatically help maintainers.
>
> Also true for having just fewer characters than are needed.  The dicey 
> part is knowing what is "needed".
>
> I've seen code where the use of cryptic, extremely short variable names 
> hurt readability.  I bet you have to (plural "you").  That shows that it 
> is possible to have too few characters in a source line to help 
> maintainers.
> -- 
> Lew

A classic case of short variable names is "Numerical Recipes in C" (or 
FORTRAN for that matter). I have a copy, and consider it valuable, but the 
code sucks pretty bad...what's valuable is the discussion. While the choice 
to use short variable names in this book was clearly driven by printing 
space requirements it hurts the readability badly. I understand the code in 
"Numerical Recipes in C++" is even worse. It's so bad that it's quite 
difficult to type out a code snippet from these books without making 
multiple errors (i.e. valid variables, just not the right ones).

Among the few super-short variable names that make sense to me are i, j, k 
for loop indices and m, n for dimensions. Contextually these are easy to 
understand and help readability (I also frequently use nr and nc instead of 
m and n).

For pretty much anything else I ensure that variable names are descriptive. 
I also find that I finetune variable name lengths according to their 
placement in code and what they are...are they object references, do they 
show up as arguments a lot, are they part of array index computations (*), 
etc.

AHS

* And if such a computation gets too long I pull it out and assign it to a 
variable. I find that readability is also hurt if the eye doesn't quickly 
grok to matching [] or () or {} pairs, modern IDEs notwithstanding, and 
doing too much inside such pairs (long variable names, lots of operators, 
function calls) can impair this. 

Arved Sandstrom wrote:
> 
> A classic case of short variable names is "Numerical Recipes in C" (or 
> FORTRAN for that matter). I have a copy, and consider it valuable, but the 
> code sucks pretty bad...what's valuable is the discussion. While the choice 
> to use short variable names in this book was clearly driven by printing 
> space requirements it hurts the readability badly. I understand the code in 
> "Numerical Recipes in C++" is even worse. It's so bad that it's quite 
> difficult to type out a code snippet from these books without making 
> multiple errors (i.e. valid variables, just not the right ones).
> 
> Among the few super-short variable names that make sense to me are i, j, k 
> for loop indices and m, n for dimensions. Contextually these are easy to 
> understand and help readability (I also frequently use nr and nc instead of 
> m and n).
> 
> For pretty much anything else I ensure that variable names are descriptive. 
> I also find that I finetune variable name lengths according to their 
> placement in code and what they are...are they object references, do they 
> show up as arguments a lot, are they part of array index computations (*), 
> etc.
> 

There are plenty of cases on mathematics where the traditional 
identifier is very short --- usually a single Greek letter. In languages 
that permit such identifiers there is little to be gained by using 
epsilon instead of ϵ.

Mark Thornton

Mark Thornton <mthornton@optrak.co.uk> writes:
>There are plenty of cases on mathematics where the traditional 
>identifier is very short --- usually a single Greek letter. In languages 
>that permit such identifiers there is little to be gained by using 
>epsilon instead of ϵ.

  You seem to have inserted the lunate epsilon U+03F5
  (I am not sure whether it is quoted correctly above).

  It might even be a valid identifier in Java, but a
  small epsilon U+03B5 might look less strange.

Lew <lew@lewscanon.com> wrote:
> Mark Space <markspace@sbc.global.net> wrote:
>>> I like to design things that can't fail, not things that rely
>>> on above average execution by the user.
> Andreas Leitgeb wrote:
>> Such a design is usually in itself a failure :-)

First of all, I admit, that I missed the "above" in the quote.
With that word, Mark's comment makes more sense, than what I 
read it as.

> I am incredulous that anyone could even think to assert that "[s]uch a design 
> is usually in itself a failure".  How could anyone think that to design 
> against failure is "itself a failure"?  That's nonsense.

I read it (wrongly) that he didn't even trust an average user.  Also,
things that can't fail must be so simple that they're not really
interesting...

On Mon, 12 May 2008, Andreas Leitgeb wrote:

> Tom Anderson <twic@urchin.earth.li> wrote:
>> On Sun, 11 May 2008, Mark Space wrote:
>>> I think "disaster hasn't struck yet" is a poor counter argument.
>> I see. Do tell me about the preparations you've made in case the sun
>> doesn't come up tomorrow morning, won't you?
>
> In this group, one should probably say explicitly, that "sun" refers
> to that shiny yellow ball in the sky usually visible on non-cloudy
> days, and not just the nickname of some company somehow related to
> Java language.

Ha! An excellent point, Herr Leitgeb, and i will endeavour to 
fully-qualify my nouns in future.

For now, please insert an:

import celestialobjects.* ;

at the top of my previous post!

tom

-- 
Argumentative and pedantic, oh, yes. Although it's properly called
"correct" -- Huge

Lew <lew@lewscanon.com> wrote:
> I've seen code where the use of cryptic, extremely short variable names hurt 
> readability.  I bet you have to (plural "you").  That shows that it is 
> possible to have too few characters in a source line to help maintainers.

I cannot parse the second sentence. My brain tells me: "unexpected EOS".

Apart from that: yes, I agree: there are cases, where too few chars do
hurt a lot. 

We seem to disagree on whether overloadable operators would change from
"too many chars" to "good", or from "good" to "too little chars".

PS: both would happen, but I weigh occurrances of first more than
those of the second.

Mark Thornton <mthornton@optrak.co.uk> wrote:
> There are plenty of cases on mathematics where the traditional 
> identifier is very short --- usually a single Greek letter. In languages 
> that permit such identifiers there is little to be gained by using 
> epsilon instead of ϵ.

The greek letter epsilon is actually "ε" and indeed perfectly legal
in Java, when using some unicode (or specifically greek) encoding.

It's one of those parts, where Java is *very* permissive beyond 
all recommendations (which discourage use of international letters)

So, in the end, there is very much gained by using "epsilon" 
(or "eps") instead of either ϵ or ε: portability to non-unicode
systems and ease of maintenance for people who do not have these
chars directly on their keyboards.

PS: I fear more that people may already use international characters
 in their code, than what they'd do if they had operators to overload.

Object ο; // This ain't ηο "o"!

Mark Thornton wrote:
> Arne Vajh�j wrote:
>> John W Kennedy wrote:
>>> 1962, actually. Logical operators first appeared in FORTRAN IV.
>>
>> This is before I was born, but I find it difficult to see how
>> they could use Fortran for much without .eq., .ne. etc..
> 
> They had an arithmetic if statement (from memory)
> 
> if(expr)labelNeg,labelZero,labelPos
> 
> The target label depended on the value of the expression. If negative 
> the first label was used, zero the second and positive values used the 
> third target. All the labels were of course integers.

I know how Fortran arithmetic if works.

But I still think it must have been a bloody nightmare to
program.

The Fortran 77 code:

       IF(I.EQ.1 .AND. J.GE.1 .AND. J.LE.3) THEN
         K = 3
         L = 4
       ELSE
         K = 5
         L = 6
       END IF

would be:

       IF(I-1) 400,100,400
100   IF(J-1) 400,200,200
200   IF(J-3) 300,300,400
300   K = 3
       L = 4
       GOTO 500
400   K = 5
       L = 6
500

That is worse than Basic.

But then of course the alternative to Fortran in 1957 was
assembler, so ...

Arne

Andreas Leitgeb wrote:

> 1) and 2)  are (imo) that "someone"'s own problem. If this 
>      "someone" is not writing for his own joy, then he'd have
 >      to follow some guidelines, anyway.

Primarily I think a variation of #2.  That someone, will out of 
ignorance mis-design grossly.  And they could do it while still 
following guidelines.  The potential for ignorance at a large 
organization is very real too.

Not so much 1, 3 and 4.



> 
> If you cannot rely on the users of a prog-language, you (in the
> role of a prog-language-designer) should instantly stop designing
> any prog-languages.

I think though that there are indeed mis-features of programming 
languages.  That operator overloading has not been included in Java 
already says (I think) Sun believes this also.  I do not think they 
should stop designing Java, and I won't stop contributing either.  Sorry 
about that.

> 
> Because *not everything* in it was bad.

What I'd really like to see is a little more discussion of what 
specifically was right about it.  I think we've degenerated a little too 
much into "yes it is" "no it isn't" and we're not making headway on 
anything resembling consensus.

Here's another idea: let's say Sun allows overloading +, -, /, and * 
only... on certain classes.  Only classes derived from java.lang.Number. 
  That'll stop people from applying overloading inappropriately to 
random parts of their design.

I realize this may be too restrictive for you, but I offer it as a way 
to further discussion.


> Generating new classes for each legible calculation on BigIntegers ?
> Strikes me as odd.

I honestly don't understand this comment.  I think perhaps there is a 
typo? Or I'm really lost...



> Good luck!  I prefer tried and tested "not-all-that-mis"-features.

You and I just disagree on this point.  It might be helpful to find some 
way to agree on something.

Patricia Shanahan wrote:

> Neither having nor not having operator overloading is risk free. The
> question, on which reasonable people can disagree, is which carries the
> higher cost.

Right.  So the important thing I think is to admit that we disagree, and 
try to find some ground where we might agree.

Is there anything less that full C++ style operator-overloading that 
would meet your current requirement?  There's a fair number of 
operations on matrices that don't use the simple style of algebraic 
operators that simple numbers use.  (My poor little brain strains to 
remember them, however.)  Should we look for a way to include those 
notations, and may be extend that to more maths?

Can we have some set of operators that you feel you really need, and 
some that would be just "nice to have?"  Are their any that you 
definitely do not need to overload?

Andreas Leitgeb wrote:
> We seem to disagree on whether overloadable operators would change from
> "too many chars" to "good", or from "good" to "too little chars".

Who told you how I feel about overloaded operators?

-- 
Lew

Arved Sandstrom wrote:

|> A classic case of short variable names is "Numerical Recipes in C" (or 
|> FORTRAN for that matter).

AFAIR, with old time FORTRAN, only the first and last letters of variable
names were significant, everything in between was silently ignored.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

Volker Borchert wrote:
> Arved Sandstrom wrote:
> |> A classic case of short variable names is "Numerical Recipes in C" (or 
> |> FORTRAN for that matter).
> 
> AFAIR, with old time FORTRAN, only the first and last letters of variable
> names were significant, everything in between was silently ignored.

Not in Fortran IV / 66 and newer.

I don't know earlier Fortran.

Arne

Andreas Leitgeb wrote:
> things that can't fail must be so simple that they're not really
> interesting...

Designing against failure doesn't necessarily prevent failure.

Done right, it often will, and then when it doesn't, it should make recovery 
more straightforward and satisfying.

The more complex or comprehensive the system, the *more* important it is to 
design against failure.

Or are you suggesting that one should just throw one's hands up and say, "This 
isn't simple, therefore I'd better just let it fail?"

-- 
Lew

Arne Vajh�j wrote:
> Volker Borchert wrote:
>> Arved Sandstrom wrote:
>> |> A classic case of short variable names is "Numerical Recipes in C" 
>> (or |> FORTRAN for that matter).
>>
>> AFAIR, with old time FORTRAN, only the first and last letters of variable
>> names were significant, everything in between was silently ignored.
> 
> Not in Fortran IV / 66 and newer.
> 
> I don't know earlier Fortran.

Well - as always it is possible to find thing son the net.

http://www.softwarepreservation.org/projects/FORTRAN/704_FortranProgRefMan_Oct56.pdf

claims that variables names are 6 letters without any mentioning of
loosing middle characters.

Arne

Mark Space <markspace@sbc.global.net> wrote:
> Here's another idea: let's say Sun allows overloading +, -, /, and * 
> only... on certain classes.  Only classes derived from java.lang.Number. 
>   That'll stop people from applying overloading inappropriately to 
> random parts of their design.

> I realize this may be too restrictive for you,

That's almost(*) the amount of overloading, that I'd be happy with.

I mentioned it in other subthreads a few times:   only arithmetic
operations for scalar types.

The restriction to "scalar" types is meant to include complex numbers,
or even quaternions, but not vectors or matrices(in the mathematical
sense).  If we added vectors, then the semantics of add and
multiplication would become ambiguous.  (piecewise adding or
concatenating; cross-product or scalar product;...)

*: I agree on the restriction to numeric types.  I wouldn't exclude
other ops, like % on BigIntegers or other ops on other classes if it
made mathemtical sense for them.

Maybe other participants in this thread would fancy C++'s philosophy
for Java, but I'm not one of those.

Mark Space <markspace@sbc.global.net> wrote:
> Right.  So the important thing I think is to admit that we disagree, and 
> try to find some ground where we might agree.

Arithmetic operations on numeric/arithmetic classes seems to be
just that ground. See the subthread with adapted subject.

> Are there any that you definitely do not need to overload?

I'd suggest those boolean operators have no such need.
Multivalued logics are not widespread enough to justify it.

Bitshift operators could be useful at least for BigInteger.

Relation operators "<",">",">=",... would be fine too, to have 
overloaded, but bear the danger, that their existence could invite
wrong expectations on "==" and "!=".

On Mon, 12 May 2008, Mark Space wrote:

> Patricia Shanahan wrote:
>
>> Neither having nor not having operator overloading is risk free. The
>> question, on which reasonable people can disagree, is which carries the
>> higher cost.
>
> Right.  So the important thing I think is to admit that we disagree, and try 
> to find some ground where we might agree.
>
> Is there anything less that full C++ style operator-overloading that would 
> meet your current requirement?  There's a fair number of operations on 
> matrices that don't use the simple style of algebraic operators that simple 
> numbers use.  (My poor little brain strains to remember them, however.) 
> Should we look for a way to include those notations, and may be extend that 
> to more maths?
>
> Can we have some set of operators that you feel you really need, and 
> some that would be just "nice to have?"  Are their any that you 
> definitely do not need to overload?

We need +, -, *, /, %, and unary - for the various kinds of complicated 
number. Also >, >=, <, <=; ideally, == and !=, but it's far too late for 
that now. Maybe we need === and !== instead. Maybe not.

We need [] and []= (ie foo[bar] = baz) for composite things like matrices, 
and possibly collections.

I'd quite like to be able to use &, |, and ^ on sets. Possibly also &=, 
|=, ^=.

I'd like to be able to gently abuse | and ^ for vectors. If i have * as a 
dot product, i can use ^ for cross product and | for the resolute.

So (with assigning forms being implied):

essential: +, -, *, /, %, >, >=, <, <=, [], []=
nice: &, |, ^
i personally don't want: ++, --, !, ~, &&, ||, ternary operator
must not have: =, .

I'd probably throw ++, --, ! and ~ into the bag, just for completeness. 
But leave the logical operators out.

tom

-- 
When you mentioned INSERT-MIND-INPUT ... did they look at you like this?

Andreas Leitgeb wrote:
> Mark Space <markspace@sbc.global.net> wrote:
>> Here's another idea: let's say Sun allows overloading +, -, /, and * 
>> only... on certain classes.  Only classes derived from java.lang.Number. 
>>   That'll stop people from applying overloading inappropriately to 
>> random parts of their design.
> 
>> I realize this may be too restrictive for you,
> 
> That's almost(*) the amount of overloading, that I'd be happy with.
> 
> I mentioned it in other subthreads a few times:   only arithmetic
> operations for scalar types.
> 
> The restriction to "scalar" types is meant to include complex numbers,
> or even quaternions, but not vectors or matrices(in the mathematical
> sense).  If we added vectors, then the semantics of add and
> multiplication would become ambiguous.  (piecewise adding or
> concatenating; cross-product or scalar product;...)
> 
> *: I agree on the restriction to numeric types.  I wouldn't exclude
> other ops, like % on BigIntegers or other ops on other classes if it
> made mathemtical sense for them.
> 
> Maybe other participants in this thread would fancy C++'s philosophy
> for Java, but I'm not one of those.

This balanced position, and others' similar posts indicate a possibility that 
a restricted operator-overload mechanism for Java would gain general 
acceptance, and that the discussion of how much to restrict the mechanism 
would achieve consensus faster than a discussion of an "all" vs. "nothing" 
implementation.

-- 
Lew

Lew wrote:
> Andreas Leitgeb wrote:
>> Mark Space <markspace@sbc.global.net> wrote:
>>> Here's another idea: let's say Sun allows overloading +, -, /, and * 
>>> only... on certain classes.  Only classes derived from 
>>> java.lang.Number.   That'll stop people from applying overloading 
>>> inappropriately to random parts of their design.
>>
>>> I realize this may be too restrictive for you,
>>
>> That's almost(*) the amount of overloading, that I'd be happy with.
>>
>> I mentioned it in other subthreads a few times:   only arithmetic
>> operations for scalar types.
>>
>> The restriction to "scalar" types is meant to include complex numbers,
>> or even quaternions, but not vectors or matrices(in the mathematical
>> sense).  If we added vectors, then the semantics of add and
>> multiplication would become ambiguous.  (piecewise adding or
>> concatenating; cross-product or scalar product;...)
>>
>> *: I agree on the restriction to numeric types.  I wouldn't exclude
>> other ops, like % on BigIntegers or other ops on other classes if it
>> made mathemtical sense for them.
>>
>> Maybe other participants in this thread would fancy C++'s philosophy
>> for Java, but I'm not one of those.
> 
> This balanced position, and others' similar posts indicate a possibility 
> that a restricted operator-overload mechanism for Java would gain 
> general acceptance, and that the discussion of how much to restrict the 
> mechanism would achieve consensus faster than a discussion of an "all" 
> vs. "nothing" implementation.
> 

I agree. I don't think operator overloading should be taken to anything
like the degree it is done in C++. In particular, I would be strongly
opposed to overloading "=". Almost all the value lies in better
representation of arithmetic expressions whose operands are references
to immutable objects.

How do people feel about overloading "[]" and ".length", so that List
and array code would be more similar? An ordered sequence type would
provide implementations for ".length", "[]" as get(), and "[]" as set().

I quite often find myself changing my mind about whether an ordered
sequence of data should be a List or an array. That can lead to warts
such as using Arrays.asList so that I can go on using get() and set()
even after turning it into an array. The refactoring would be easier if
I could use the same code for the operations they have in common.

Patricia

Patricia Shanahan wrote:
....
> How do people feel about overloading "[]" and ".length", so that List
> and array code would be more similar? An ordered sequence type would
> provide implementations for ".length", "[]" as get(), and "[]" as set().
....

Another thought on this idea. Maybe the compiler should just map
".length" to size() and "[]" to get() or set() whenever one of them is
applied to a reference of type List, or any type extending or
implementing List. The methods are already guaranteed to exist, and to
have the necessary meanings.

Patricia

Patricia Shanahan wrote:
> How do people feel about overloading "[]" and ".length", so that List
> and array code would be more similar? An ordered sequence type would
> provide implementations for ".length", "[]" as get(), and "[]" as set().

The overload of brackets, usually square, to represent associative maps is 
another popular request.  This is supported in many scripting languages, 
including Java's own EL web scripting language.  As others have mentioned 
within this thread, modern Java's support of scripts might obviate the need to 
overload certain operators in Java proper.

C# provides some models for what people might want in overloaded [] and ().

-- 
Lew

josh wrote :
> operator overloading

I am reading this discussion and I shudder.

Can we not keep operator overloading out of the Java spec?

Using descriptive method names leaves no ambiguity as to what will 
happen, whereas with operator overloading you need to make a best 
"guess" at what the writer meant by the operator he/she chose for an 
operation.

Yes, I have written in C++, and yes I have used operator overloading. 
Unless you and the writer are in the same mind-set the only way to 
ferret out what is happening is to dig into the source code.

Give me descriptive names every time. With modern IDEs long method 
names are not the pain they used to be as the IDE provides code assist.

So rather than trying to "fit" a symbol into an operation, use a 
descriptive method name.

To me operator overloading is one of those things that is neat to do, 
somewhat like all the shortcut symbols in Perl, but it introduces huge 
maintenance problems.

-- 
Wojtek :-)

Wojtek wrote:
> josh wrote :
>> operator overloading
> 
> I am reading this discussion and I shudder.
> 
> Can we not keep operator overloading out of the Java spec?
> 
> Using descriptive method names leaves no ambiguity as to what will 
> happen, whereas with operator overloading you need to make a best 
> "guess" at what the writer meant by the operator he/she chose for an 
> operation.
> 
> Yes, I have written in C++, and yes I have used operator overloading. 
> Unless you and the writer are in the same mind-set the only way to 
> ferret out what is happening is to dig into the source code.
> 
> Give me descriptive names every time. With modern IDEs long method names 
> are not the pain they used to be as the IDE provides code assist.

I actually strongly agree with this. The place where we differ is that I
feel that "+" is the most descriptive, clearest symbol possible for
arithmetic addition. Using it for anything else, including String
concatenation, is just as bad as using a misleading method name.

The challenge I presented earlier in this thread is a *very* simple
example of a mathematical formula:

"Consider calculating the sum of the first n terms of an arithmetic
series, given its first term, a1, and common difference, d.
http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29

Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."

Can you produce a descriptive method name form of this expression that
is as obviously equivalent to the original formula?

Patricia

Patricia Shanahan wrote :
> The challenge I presented earlier in this thread is a *very* simple
> example of a mathematical formula:
>
> "Consider calculating the sum of the first n terms of an arithmetic
> series, given its first term, a1, and common difference, d.
> http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29
>
> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."
>
> Can you produce a descriptive method name form of this expression that
> is as obviously equivalent to the original formula?

Ok, this appears to be used as a utility method, therefore I would make 
it static with the method returning the result of the formulae 
calculation. The class could be named MyMath. So:

BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
termLimit, difference);

-- 
Wojtek :-)

On Tue, 13 May 2008, Patricia Shanahan wrote:

> Lew wrote:
>> Andreas Leitgeb wrote:
>>> Mark Space <markspace@sbc.global.net> wrote:
>>>> Here's another idea: let's say Sun allows overloading +, -, /, and * 
>>>> only... on certain classes.  Only classes derived from java.lang.Number. 
>>>> That'll stop people from applying overloading inappropriately to random 
>>>> parts of their design.
>>> 
>>> That's almost(*) the amount of overloading, that I'd be happy with.
>>> 
>>> I mentioned it in other subthreads a few times:   only arithmetic
>>> operations for scalar types.
>> 
>> This balanced position, and others' similar posts indicate a possibility 
>> that a restricted operator-overload mechanism for Java would gain general 
>> acceptance, and that the discussion of how much to restrict the mechanism 
>> would achieve consensus faster than a discussion of an "all" vs. "nothing" 
>> implementation.
>
> I agree. I don't think operator overloading should be taken to anything
> like the degree it is done in C++. In particular, I would be strongly
> opposed to overloading "=". Almost all the value lies in better
> representation of arithmetic expressions whose operands are references
> to immutable objects.
>
> How do people feel about overloading "[]" and ".length", so that List 
> and array code would be more similar? An ordered sequence type would 
> provide implementations for ".length", "[]" as get(), and "[]" as set().

You will not be surprised to hear that i'm in favour of it.

> I quite often find myself changing my mind about whether an ordered 
> sequence of data should be a List or an array. That can lead to warts 
> such as using Arrays.asList so that I can go on using get() and set() 
> even after turning it into an array. The refactoring would be easier if 
> I could use the same code for the operations they have in common.

Another option would be to have T[] implement List<T>, and behave like an 
Arrays.asList list.

Maybe the solution is to make general provision in the language for 
applying operators to objects, but none at all for defining overloaded 
operators. Then make general provision in the VM for both. Sun [1] could 
then apply magic to such library classes as it saw fit (String, the 
primitive wrappers, BigInteger, BigDecimal, and some new general-purpose 
Complex, Vector etc classes in java.math). This would give us the few 
operatorable classes that are needed to cover 90% of all potential uses, 
and wouldn't give ordinary programmers the ability to create new ones.

Those who desperately wanted to write overloaded operators would be free 
to use a not-java, or not-quite-java, language that supports them and 
compiles to java bytecode. But then they wouldn't be writing java. This is 
exactly the situation we have now, where various languages supporting 
operator overloading compile to bytecode.

The one thing this couldn't do is collections. If you add [] to List, you 
have to give people a way to implement it. If List was an abstract class 
rather than an interface, you could magic [] into the abse class and have 
it punt to get, which people could implement. But it's not, so you can't.

tom

[1] The company, not the star.

-- 
When you mentioned INSERT-MIND-INPUT ... did they look at you like this?

Wojtek wrote:

> Ok, this appears to be used as a utility method, therefore I would make 
> it static with the method returning the result of the formulae 
> calculation. The class could be named MyMath. So:
> 
> BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
> termLimit, difference);
> 

Oops.  That was actually a really good answer. :)

Wojtek wrote:
> Patricia Shanahan wrote :
>> The challenge I presented earlier in this thread is a *very* simple
>> example of a mathematical formula:
>>
>> "Consider calculating the sum of the first n terms of an arithmetic
>> series, given its first term, a1, and common difference, d.
>> http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29 
>>
>>
>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."
>>
>> Can you produce a descriptive method name form of this expression that
>> is as obviously equivalent to the original formula?
> 
> Ok, this appears to be used as a utility method, therefore I would make 
> it static with the method returning the result of the formulae 
> calculation. The class could be named MyMath. So:
> 
> BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
> termLimit, difference);
> 

Maybe, you know, document too...

public class MyMath {
   private MyMath {}

   /** Calculates the arithmetic progression for n terms.
    *
    * Uses the formula: (n * (2*a1 + (n-1)*d))/2
    */
   public static double getProgressionSeriesSum( double startTerm,
            double termLimit, double difference)
   {
     // ...
   }
}

Mark Space wrote :
> Maybe, you know, document too...

Well yes of course :-)

I was just illustrating that the method name gave enough information, 
plus that not all editing environments pop-up JavaDoc

-- 
Wojtek :-)

Patricia Shanahan wrote :
> I actually strongly agree with this. The place where we differ is that I
> feel that "+" is the most descriptive, clearest symbol possible for
> arithmetic addition. Using it for anything else, including String
> concatenation, is just as bad as using a misleading method name.

Yes.

And the people at PHP agree with that as PHP string concatination is 
done with a period.

It is too late to do anything about it though. Think of the millions of 
LOC that would be affected...

-- 
Wojtek :-)

Andreas Leitgeb wrote:
> Mark Space <markspace@sbc.global.net> wrote:
>> Here's another idea: let's say Sun allows overloading +, -, /, and * 
>> only... on certain classes.  Only classes derived from java.lang.Number. 
>>   That'll stop people from applying overloading inappropriately to 
>> random parts of their design.
> 
>> I realize this may be too restrictive for you,
> 
> That's almost(*) the amount of overloading, that I'd be happy with.
> 
> I mentioned it in other subthreads a few times:   only arithmetic
> operations for scalar types.
> 

Yes, sorry if I just retyped someone else's suggestion. I thought I had 
seen this (only java.lang.Number and subclasses) idea before, but I 
couldn't be sure.

Anyway, these suggestions sound very reasonable and well scoped. This 
would be ok with me.

Patricia Shanahan wrote:

> How do people feel about overloading "[]" and ".length", so that List
> and array code would be more similar? An ordered sequence type would
> provide implementations for ".length", "[]" as get(), and "[]" as set().

"length" confuses me because it's not an operator.  Also I don't see 
much readability difference between "length" and "length()".  (Or 
"size()" for that matter.)

[] is interesting.  Perhaps only for subclasses of AbstractSet, 
AbstractList and AbstractMap?

There's still the decision for what type(s) get() and set() take.  Ints? 
Parameterized types?   How many? "set()" for Set and List might be 
different.  Hmm, actually I don't think set() works for Set

   Set<Integer> sieve = //...
   sieve[2] = // ...??

Don't know about that.  Using add and remove might be much clearer. 
"get()"'s ok, it should return true or false depending if the object is 
present in the set.

   if( sieve[3] )
   {
      // do something
   }

Wojtek wrote:
> Patricia Shanahan wrote :
>> The challenge I presented earlier in this thread is a *very* simple
>> example of a mathematical formula:
>>
>> "Consider calculating the sum of the first n terms of an arithmetic
>> series, given its first term, a1, and common difference, d.
>> http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29 
>>
>>
>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."
>>
>> Can you produce a descriptive method name form of this expression that
>> is as obviously equivalent to the original formula?
> 
> Ok, this appears to be used as a utility method, therefore I would make 
> it static with the method returning the result of the formulae 
> calculation. The class could be named MyMath. So:
> 
> BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
> termLimit, difference);
> 

So what does the code inside seriesSum look like? Remember this is just
a *very* simple example of the sort of thing that shows up all over
engineering and scientific programs.

Patricia

Mark Space wrote:
> Patricia Shanahan wrote:
> 
> Can we have some set of operators that you feel you really need, and 
> some that would be just "nice to have?"  Are their any that you 
> definitely do not need to overload?
> 

Essential:

Binary operators: +,-,*,/
Unary operators: +,-


On BigInteger, BigDecimal, and complex (float and double forms).

Plus comparison operators (<, <=, ==, !=, >=, >) and remainder (%) on 
Big*, but not complex values.

Very nice to have:
[] operator for matrix element access.

That would be it. Interval arithmetic and rational numbers would be nice 
too, but neither is in widespread use. So I would just do the set above 
and not implement user overloading of operators.

Mark Thornton

Wojtek wrote:
> Patricia Shanahan wrote :
>> The challenge I presented earlier in this thread is a *very* simple
>> example of a mathematical formula:
>>
>> "Consider calculating the sum of the first n terms of an arithmetic
>> series, given its first term, a1, and common difference, d.
>> http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29 
>>
>>
>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."
>>
>> Can you produce a descriptive method name form of this expression that
>> is as obviously equivalent to the original formula?
> 
> Ok, this appears to be used as a utility method, therefore I would make 
> it static with the method returning the result of the formulae 
> calculation. The class could be named MyMath. So:
> 
> BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
> termLimit, difference);
> 

I think you have missed the point. It is just a fragment of code and we 
don't want to turn every such fragment into a method of its own. It is 
also on the very simple end of mathematical expressions.

Mark Thornton

Mark Thornton wrote :
> Wojtek wrote:
>> Patricia Shanahan wrote :
>>> The challenge I presented earlier in this thread is a *very* simple
>>> example of a mathematical formula:
>>>
>>> "Consider calculating the sum of the first n terms of an arithmetic
>>> series, given its first term, a1, and common difference, d.
>>> http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29
>>>
>>>
>>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."
>>>
>>> Can you produce a descriptive method name form of this expression that
>>> is as obviously equivalent to the original formula?
>> 
>> Ok, this appears to be used as a utility method, therefore I would make it 
>> static with the method returning the result of the formulae calculation. 
>> The class could be named MyMath. So:
>> 
>> BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
>> termLimit, difference);
>> 
>
> I think you have missed the point. It is just a fragment of code and we don't 
> want to turn every such fragment into a method of its own. It is also on the 
> very simple end of mathematical expressions.

Also to Patricia,

The series sum is a pure math operation, and would not need operator 
overloading.

And yes, I WOULD create a library with these types of calls. It makes 
using them in multiple places consistent. I would encase it even for a 
single use as it makes cleaner code at the point of usage.

What the formula is like in the method is up to the author. Black box 
testing should prove that the formula implementation is correct. If you 
do not have trust in the author, then extend the library class and 
override the method with your own implementation.

But that is always the risk in using someone elses library for 
everything from high math formula to common string operations. The 
assumption is that it works until proven false. If you are using the 
library for mission critical use (life critical, million dollar 
critical) then you would perform extensive testing before it was 
trusted.

Maybe I am missing the point with this series sum formula. It just 
seems obvious to me to encase it in a method, prove it, then just use 
it.

And how it relates to operator overloading mistifies me.

-- 
Wojtek :-)

Wojtek wrote:
> Mark Thornton wrote :
>> Wojtek wrote:
>>> Patricia Shanahan wrote :
>>>> The challenge I presented earlier in this thread is a *very* simple
>>>> example of a mathematical formula:
>>>>
>>>> "Consider calculating the sum of the first n terms of an arithmetic
>>>> series, given its first term, a1, and common difference, d.
>>>> http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29 
>>>>
>>>>
>>>>
>>>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."
>>>>
>>>> Can you produce a descriptive method name form of this expression that
>>>> is as obviously equivalent to the original formula?
>>>
>>> Ok, this appears to be used as a utility method, therefore I would 
>>> make it static with the method returning the result of the formulae 
>>> calculation. The class could be named MyMath. So:
>>>
>>> BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
>>> termLimit, difference);
>>>
>>
>> I think you have missed the point. It is just a fragment of code and 
>> we don't want to turn every such fragment into a method of its own. It 
>> is also on the very simple end of mathematical expressions.
> 
> Also to Patricia,
> 
> The series sum is a pure math operation, and would not need operator 
> overloading.

Suppose the arithmetic series is a series of BigDecimal? I have yet to
see a version without infix arithmetic operators that is as clear, and
as obviously equivalent to the referenced formula.

> And yes, I WOULD create a library with these types of calls. It makes 
> using them in multiple places consistent. I would encase it even for a 
> single use as it makes cleaner code at the point of usage.
> 
> What the formula is like in the method is up to the author. Black box 
> testing should prove that the formula implementation is correct. If you 
> do not have trust in the author, then extend the library class and 
> override the method with your own implementation.

I believe in defense in depth against errors. Yes, I do black box
testing, but I also want to be able to write the code with low risk of
error, and desk check it with high probability of seeing any errors. In
the case of the Java representation of a mathematical formula, that
includes checking that the code is equivalent to the formula.

Libraries only push the problem back a layer. Someone has to write the
library method. Ideally, at least one colleague will review it. Someone
has to maintain it. Their ability to do so efficiently depends on the
readability of the library implementation.

Patricia

Patricia Shanahan wrote:
> I agree. I don't think operator overloading should be taken to anything
> like the degree it is done in C++. In particular, I would be strongly
> opposed to overloading "=". Almost all the value lies in better
> representation of arithmetic expressions whose operands are references
> to immutable objects.

What about operator&& or operator,? And C++ didn't go all the way: 
imagine operator?: . Now THAT would make for some fun obfuscations. :-)

> How do people feel about overloading "[]" and ".length", so that List
> and array code would be more similar? An ordered sequence type would
> provide implementations for ".length", "[]" as get(), and "[]" as set().

To me, the presence of a pseudo-variable `.length' feels as if it could 
be modifiable. I'm not heavily committed one way or the other on 
overloading `.length', although I would probably rather see an array get 
a .size() or .isEmpty() "function" instead.

> I quite often find myself changing my mind about whether an ordered
> sequence of data should be a List or an array. That can lead to warts
> such as using Arrays.asList so that I can go on using get() and set()
> even after turning it into an array. The refactoring would be easier if
> I could use the same code for the operations they have in common.

+1


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Mark Thornton wrote:

> Plus comparison operators (<, <=, ==, !=, >=, >) and remainder (%) on 

== and != are the only ones that bother me.  The other comparison 
operators have no meaning on reference values, but == and != do.

I admit, I can't think of a good use for == for references (other than 
inside a comparison operator to test for identity) but it would be kind 
of irregular for the language to treat these differently.

I'm looking for a way around overloading those two, or at least a way to 
distinguish testa for identity from a comparison of the object.

The other thing is absolutely everything uses equals() anyway, including 
strings, so maybe specifically not overloading == and != might be ok.

And unlike, say num1.greaterThan( num2 ) you don't have to stop and 
think about which way the operator (> in this case) should really point. 
  It's the same in both directions for .equals().  That is, num1.equals( 
num2 ) and num2.equals( num1 ).

Just thinking out loud....

Wojtek wrote:
> Mark Thornton wrote :
>> Wojtek wrote:
>>> Patricia Shanahan wrote :
>>>> The challenge I presented earlier in this thread is a *very* simple
>>>> example of a mathematical formula:
>>>>
>>>> "Consider calculating the sum of the first n terms of an arithmetic
>>>> series, given its first term, a1, and common difference, d.
>>>> http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29 
>>>>
>>>>
>>>>
>>>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."
>>>>
>>>> Can you produce a descriptive method name form of this expression that
>>>> is as obviously equivalent to the original formula?
>>>
>>> Ok, this appears to be used as a utility method, therefore I would 
>>> make it static with the method returning the result of the formulae 
>>> calculation. The class could be named MyMath. So:
>>>
>>> BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
>>> termLimit, difference);
>>>
>>
>> I think you have missed the point. It is just a fragment of code and 
>> we don't want to turn every such fragment into a method of its own. It 
>> is also on the very simple end of mathematical expressions.
> 
> Also to Patricia,
> 
> The series sum is a pure math operation, and would not need operator 
> overloading.
> 
> And yes, I WOULD create a library with these types of calls. It makes 
> using them in multiple places consistent. I would encase it even for a 
> single use as it makes cleaner code at the point of usage.
> 
> What the formula is like in the method is up to the author. Black box 
> testing should prove that the formula implementation is correct. If you 
> do not have trust in the author, then extend the library class and 
> override the method with your own implementation.
> 
> But that is always the risk in using someone elses library for 
> everything from high math formula to common string operations. The 
> assumption is that it works until proven false. If you are using the 
> library for mission critical use (life critical, million dollar 
> critical) then you would perform extensive testing before it was trusted.
> 
> Maybe I am missing the point with this series sum formula. It just seems 
> obvious to me to encase it in a method, prove it, then just use it.

I think that James Gosling has observed that people who are not 
mathematicians/engineers almost invariably miss the point with regard to 
the desireability of operator overloading at least for complex 
arithmetic. In part I think it is the expression itself, in STANDARD 
form, which is recognised, not the name which you might give it. Others 
have said that the language of mathematicians is not 
English/French/German or any other natural language but symbolic with 
centuries of history. Its representation in software is necessarily 
approximate, but words are not the answer. Or at least not the answer 
desired by mathematicians.
Does forcing the use of words make the result more comprehensible to non 
mathematicians? In my experience the answer is no, the code remains as 
black box as ever to those without sufficient maths background.

Mark Thornton

Patricia Shanahan wrote :
>> The series sum is a pure math operation, and would not need operator 
>> overloading.
>
> Suppose the arithmetic series is a series of BigDecimal? I have yet to
> see a version without infix arithmetic operators that is as clear, and
> as obviously equivalent to the referenced formula.

A light shines...

Yes, that would be a bit awkward.

I would probably break down the formula into a series of discrete 
steps, each on its own line, along with a lot of comments of what is 
really going on.

But that would not look like the formula.

>> And yes, I WOULD create a library with these types of calls. It makes using 
>> them in multiple places consistent. I would encase it even for a single use 
>> as it makes cleaner code at the point of usage.
>>  
>> What the formula is like in the method is up to the author. Black box 
>> testing should prove that the formula implementation is correct. If you do 
>> not have trust in the author, then extend the library class and override 
>> the method with your own implementation.
>
> I believe in defense in depth against errors. Yes, I do black box
> testing, but I also want to be able to write the code with low risk of
> error, and desk check it with high probability of seeing any errors. In
> the case of the Java representation of a mathematical formula, that
> includes checking that the code is equivalent to the formula.
>
> Libraries only push the problem back a layer. Someone has to write the
> library method. Ideally, at least one colleague will review it. Someone
> has to maintain it. Their ability to do so efficiently depends on the
> readability of the library implementation.

Test, test, test, then test again :-)

-- 
Wojtek :-)

Mark Thornton wrote:
....
> I think that James Gosling has observed that people who are not 
> mathematicians/engineers almost invariably miss the point with regard to 
> the desireability of operator overloading at least for complex 
> arithmetic. In part I think it is the expression itself, in STANDARD 
> form, which is recognised, not the name which you might give it. Others 
> have said that the language of mathematicians is not 
> English/French/German or any other natural language but symbolic with 
> centuries of history. Its representation in software is necessarily 
> approximate, but words are not the answer. Or at least not the answer 
> desired by mathematicians.
....

Although I've spent most of my life as a software or hardware developer,
my bachelor's degree was in mathematics. That may explain some of my
thinking on this subject. To me, the mathematical formula is the
clearest, most understandable representation. The closer the computer
program representation gets to that, the better.

Patricia

Mark Thornton wrote :
> Does forcing the use of words make the result more comprehensible to non 
> mathematicians? In my experience the answer is no, the code remains as black 
> box as ever to those without sufficient maths background.

Programming always is abstracted from reality.

And translation between the real world and code can be a real 
challenge.

For most projects I can learn enough from the SME to be able to mimic 
what they think they want.

But real mathematics is still a mystery to me. I can break down 
relatively simple formulas like the series sum above, but I know my 
limits.

And I think I have changed my mind about operator overloading, but only 
as defined by the language rather than a free-for-all.

So things like:

Double a = new Double(5.0);
Double b = new Double(7.5);
Double c = a + b;

would be allowed as it relates to numbers. Programmer defined operator 
overloading would be forbidden like it is now.

-- 
Wojtek :-)

Mark Space wrote:
> Mark Thornton wrote:
> 
>> Plus comparison operators (<, <=, ==, !=, >=, >) and remainder (%) on 
> 
> == and != are the only ones that bother me.  The other comparison 
> operators have no meaning on reference values, but == and != do.
> 

They are indeed a problem. Apart from comparison to null (another 
awkward case) there are no good reasons for using reference equality 
with BigInteger/BigDecimal or any of the primitive wrappers. 
Nevertheless the language currently allows it, so no doubt some 
programmers have done so.

Mark Thornton

Wojtek wrote:
> Mark Thornton wrote :
>> Does forcing the use of words make the result more comprehensible to 
>> non mathematicians? In my experience the answer is no, the code 
>> remains as black box as ever to those without sufficient maths 
>> background.
> 
> Programming always is abstracted from reality.
> 
> And translation between the real world and code can be a real challenge.
> 
> For most projects I can learn enough from the SME to be able to mimic 
> what they think they want.
> 
> But real mathematics is still a mystery to me. I can break down 
> relatively simple formulas like the series sum above, but I know my limits.
> 
> And I think I have changed my mind about operator overloading, but only 
> as defined by the language rather than a free-for-all.
> 
> So things like:
> 
> Double a = new Double(5.0);
> Double b = new Double(7.5);
> Double c = a + b;
> 
> would be allowed as it relates to numbers. Programmer defined operator 
> overloading would be forbidden like it is now.
> 

Without programmer defined operator overloading, the language has to
define all the arithmetic types. Currently, it is missing, as language
features, complex (based on each of float and double), rational, and
interval arithmetic.

Of those, complex is the most basic and essential. Fortran has supported
it, as the equivalent of a Java primitive type, for decades.

Patricia

Wojtek wrote:
> 
> I would probably break down the formula into a series of discrete steps, 
> each on its own line, along with a lot of comments of what is really 
> going on.
Whereas a mathematician would see it as elementary and not requiring 
further comment. From memory my copy of A&S lists that formula in 
chapter 1 without much comment.

Mark Thornton

P.S. A&S = Abramowitz and Stegun, Handbook of mathematical formula.

Patricia Shanahan wrote:
> Mark Thornton wrote:
> ...
>> I think that James Gosling has observed that people who are not 
>> mathematicians/engineers almost invariably miss the point with regard 
>> to the desireability of operator overloading at least for complex 
>> arithmetic. In part I think it is the expression itself, in STANDARD 
>> form, which is recognised, not the name which you might give it. 
>> Others have said that the language of mathematicians is not 
>> English/French/German or any other natural language but symbolic with 
>> centuries of history. Its representation in software is necessarily 
>> approximate, but words are not the answer. Or at least not the answer 
>> desired by mathematicians.
> ...
> 
> Although I've spent most of my life as a software or hardware developer,
> my bachelor's degree was in mathematics. That may explain some of my
> thinking on this subject. To me, the mathematical formula is the
> clearest, most understandable representation. The closer the computer
> program representation gets to that, the better.
> 
> Patricia

Agreed,

Mark Thornton
(PhD, Applied Mathematics)

Patricia Shanahan wrote:
> Wojtek wrote:
>> Mark Thornton wrote :
>>> Does forcing the use of words make the result more comprehensible to 
>>> non mathematicians? In my experience the answer is no, the code 
>>> remains as black box as ever to those without sufficient maths 
>>> background.
>>
>> Programming always is abstracted from reality.
>>
>> And translation between the real world and code can be a real challenge.
>>
>> For most projects I can learn enough from the SME to be able to mimic 
>> what they think they want.
>>
>> But real mathematics is still a mystery to me. I can break down 
>> relatively simple formulas like the series sum above, but I know my 
>> limits.
>>
>> And I think I have changed my mind about operator overloading, but 
>> only as defined by the language rather than a free-for-all.
>>
>> So things like:
>>
>> Double a = new Double(5.0);
>> Double b = new Double(7.5);
>> Double c = a + b;
>>
>> would be allowed as it relates to numbers. Programmer defined operator 
>> overloading would be forbidden like it is now.
>>
> 
> Without programmer defined operator overloading, the language has to
> define all the arithmetic types. Currently, it is missing, as language
> features, complex (based on each of float and double), rational, and
> interval arithmetic.
> 
> Of those, complex is the most basic and essential. Fortran has supported
> it, as the equivalent of a Java primitive type, for decades.
> 
> Patricia

Adding complex (and perhaps rational) as primitives would be the 
simplest pragmatic solution and deal with perhaps 90% of the well 
justified requirements for operator overloading. Of course it offends 
against principal as these types are undeniably composites of other 
primitives.

Mark Thornton

On Tue, 13 May 2008 22:05:34 +0100, Patricia Shanahan <pats@acm.org> wrote:

> Suppose the arithmetic series is a series of BigDecimal? I have yet to
> see a version without infix arithmetic operators that is as clear, and
> as obviously equivalent to the referenced formula.
>
>> And yes, I WOULD create a library with these types of calls. It makes  
>> using them in multiple places consistent. I would encase it even for a  
>> single use as it makes cleaner code at the point of usage.
>>  What the formula is like in the method is up to the author. Black box  
>> testing should prove that the formula implementation is correct. If you  
>> do not have trust in the author, then extend the library class and  
>> override the method with your own implementation.
>
> I believe in defense in depth against errors. Yes, I do black box
> testing, but I also want to be able to write the code with low risk of
> error, and desk check it with high probability of seeing any errors. In
> the case of the Java representation of a mathematical formula, that
> includes checking that the code is equivalent to the formula.

I agree.  On my last project I had to deal with a whole load of  
calculations that used BigDecimals, and they were a nightmare to maintain.

In the end I ended up implementing all of the formulae in Haskell as a  
sanity check.  The Haskell version was concise and very close to being a  
straight transcription of the specification.  I was then able to use this  
version to generate expected values for a big set of unit tests.  After  
fixing the bugs and attaining 100% test coverage I was reasonably  
confident that the Java version was correct, but I would be extremely  
reluctant to use Java for any non-trivial arbitrary-precision arithmetic  
again.

> Libraries only push the problem back a layer. Someone has to write the
> library method. Ideally, at least one colleague will review it. Someone
> has to maintain it. Their ability to do so efficiently depends on the
> readability of the library implementation.

I wrote about some of the problems of using BigDecimals previously (lack  
of operators, compareTo being incosistent with equals, etc.):

http://blog.uncommons.org/2007/06/25/bigdecimal-gotchas-and-the-need-for-overloaded-operators/

Dan.

-- 
Daniel Dyer
http://www.uncommons.org

On Tue, 13 May 2008, Mark Thornton wrote:

> Patricia Shanahan wrote:
>> Wojtek wrote:
>>> Mark Thornton wrote :
>>>> Does forcing the use of words make the result more comprehensible to non 
>>>> mathematicians? In my experience the answer is no, the code remains as 
>>>> black box as ever to those without sufficient maths background.
>>> 
>>> And I think I have changed my mind about operator overloading, but only as 
>>> defined by the language rather than a free-for-all.
>>> 
>>> So things like:
>>> 
>>> Double a = new Double(5.0);
>>> Double b = new Double(7.5);
>>> Double c = a + b;
>>> 
>>> would be allowed as it relates to numbers. Programmer defined operator 
>>> overloading would be forbidden like it is now.
>> 
>> Without programmer defined operator overloading, the language has to
>> define all the arithmetic types. Currently, it is missing, as language
>> features, complex (based on each of float and double), rational, and
>> interval arithmetic.
>> 
>> Of those, complex is the most basic and essential. Fortran has supported
>> it, as the equivalent of a Java primitive type, for decades.
>
> Adding complex (and perhaps rational) as primitives would be the 
> simplest pragmatic solution and deal with perhaps 90% of the well 
> justified requirements for operator overloading.

I disagree with you and Patricia here: i suspect that many, many more 
people would use Vector3D than Complex. Who uses complex numbers anyway? 
Just crazy maths types. Vector3D would turn up every time anyone did 3D 
graphics or any kind of 3D spatial work.

Unless you're thinking of using Complex as a Vector2D, which you could. 
Then, it might be more popular than Vector3D.

> Of course it offends against principal as these types are undeniably 
> composites of other primitives.

Careful - that sounds like an argument for removing every primitive except 
boolean! And, if we get closures, even that.

tom

-- 
What's hit's history; what's missed's mystery.

Mark Thornton wrote:
> Mark Space wrote:
>> Mark Thornton wrote:
>>
>>> Plus comparison operators (<, <=, ==, !=, >=, >) and remainder (%) on 
>>
>> == and != are the only ones that bother me.  The other comparison 
>> operators have no meaning on reference values, but == and != do.
>>
> 
> They are indeed a problem. Apart from comparison to null (another 
> awkward case) there are no good reasons for using reference equality 
> with BigInteger/BigDecimal or any of the primitive wrappers. 
> Nevertheless the language currently allows it, so no doubt some 
> programmers have done so.

The problem isn't whether BigInteger needs reference equality, but how much 
damage a redefinition of == just for a couple of classes might cause.

The whole == vs. equals() dichotomy is a pretty fundamental Javaism.

-- 
Lew

On Wed, 14 May 2008 00:48:37 +0100, Lew <lew@lewscanon.com> wrote:

> Mark Thornton wrote:
>> Mark Space wrote:
>>> Mark Thornton wrote:
>>>
>>>> Plus comparison operators (<, <=3D, =3D=3D, !=3D, >=3D, >) and rema=
inder (%) on
>>>
>>> =3D=3D and !=3D are the only ones that bother me.  The other compari=
son  =

>>> operators have no meaning on reference values, but =3D=3D and !=3D d=
o.
>>>
>>  They are indeed a problem. Apart from comparison to null (another  =

>> awkward case) there are no good reasons for using reference equality =
 =

>> with BigInteger/BigDecimal or any of the primitive wrappers.  =

>> Nevertheless the language currently allows it, so no doubt some  =

>> programmers have done so.
>
> The problem isn't whether BigInteger needs reference equality, but how=
  =

> much damage a redefinition of =3D=3D just for a couple of classes migh=
t  =

> cause.
>
> The whole =3D=3D vs. equals() dichotomy is a pretty fundamental Javais=
m.

It gets worse in the case of BigDecimal, because 2.0 is not considered  =

equal to 2.00.  As a result, compareTo is inconsistent with equals.  So =
if  =

you overload =3D=3D, which behaviour should it have?  Should it be consi=
stent  =

with equals or with compareTo?  I think you'd have to go with compareTo,=
  =

just so that =3D=3D remained consistent with <=3D and >=3D, but I don't =
really  =

like either option.

Dan.

-- =

Daniel Dyer
http://www.uncommons.org

Tom Anderson wrote:
....
> I disagree with you and Patricia here: i suspect that many, many more 
> people would use Vector3D than Complex. Who uses complex numbers anyway? 
> Just crazy maths types. Vector3D would turn up every time anyone did 3D 
> graphics or any kind of 3D spatial work.
....

Actually, in my experience it is more "practical engineer types" than
"crazy maths types". Of course, anyone who really cares about this is
likely to be someone who thinks in mathematical formulas, but that
applies to a lot of engineers.

Given their origin as a way of simplifying the rules for the numbers of
roots of polynomials, complex numbers turned out to be surprisingly useful.

Patricia

Joshua Cranmer wrote:
> To me, the presence of a pseudo-variable `.length' feels as if it could 
> be modifiable. I'm not heavily committed one way or the other on 
> overloading `.length', although I would probably rather see an array get 
> a .size() or .isEmpty() "function" instead.

Given the existence of the 'final' keyword, even a real, non-pseudo instance 
variable could be non-modifiable.  Why shouldn't 'length' be immutable?

-- 
Lew

Wojtek wrote:
> What the formula is like in the method is up to the author. Black box 
> testing should prove that the formula implementation is correct. If you 
> do not have trust in the author, then extend the library class and 
> override the method with your own implementation.

Nitpicker here.

If these are static utility methods they will not be overridable.  Your 
example upthread used a static utility method.

If the utility class is declared final, as it likely should be, even instance 
methods will not be overridable.

This just goes to elevate the necessary level of API trust of which you 
eloquently spoke.  The usual and best reaction to an untrustworthy API is not 
to extend it, trying to make a silk purse out of a sow's ear, but to abandon 
it in favor of one that works.  This strengthens your point about extensive 
testing commensurate with the level of risk accepted.

-- 
Lew

Mark Space <markspace@sbc.global.net> wrote:
> "length" confuses me because it's not an operator.  Also I don't see 
> much readability difference between "length" and "length()".  (Or 
> "size()" for that matter.)

arrays are just too different from Collections.
If I could pass an array to a function taking e.g. a List,
then the array would need to have real methods, that implement
the interface's methods. This also breaks with arrays of primitive
types.  I don't think, this is a good way to go.

I do not propose using brackets for anything else than arrays, 
but that should not stop me from discussing it anyway:

>    Set<Integer> sieve = //...
>    sieve[2] = // ...??
>    if( sieve[3] )

Set      read: .exists() -- write: .add() or .remove, depending on whether
             true or false is written to it. 
List     read: .get() -- write: .set()
Map      read: .get() -- write: .put()

Sounds good so far, but what to do with classes that implement more than
one of those?

I'd rather concentrate on sane arithmetics with special numeric classes
for now.

"Lew" <lew@lewscanon.com> wrote in message 
news:9_mdnYT4xZoKC7TVnZ2dnUVZ_s_inZ2d@comcast.com...
> Patricia Shanahan wrote:
>> How do people feel about overloading "[]" and ".length", so that List
>> and array code would be more similar? An ordered sequence type would
>> provide implementations for ".length", "[]" as get(), and "[]" as set().
>
> The overload of brackets, usually square, to represent associative maps is 
> another popular request.  This is supported in many scripting languages, 
> including Java's own EL web scripting language.  As others have mentioned 
> within this thread, modern Java's support of scripts might obviate the 
> need to overload certain operators in Java proper.
>
> C# provides some models for what people might want in overloaded [] and 
> ().
> -- 
> Lew

Wrt indexers Ruby is also a model, which again allows for a nice definition 
of [] for a user class. In both cases (C# and Ruby) what's appealing is that 
the key type is unrestricted, so it can be an integer (for array-like 
indexing), or a string (for map-like lookup), or anything else that make 
sense. C# indexers may also have more than one parameter, and although I am 
not fluent in Ruby I'd guess it supports that also.

C# user defined type conversions (explicit use of ()) is also quite useful 
in situations.

So I'd potentially add these to what Andreas has to say:

"Andreas Leitgeb" <avl@gamma.logic.tuwien.ac.at> wrote in message 
news:slrng2il7i.6ga.avl@gamma.logic.tuwien.ac.at...
[ SNIP ]
> That's almost(*) the amount of overloading, that I'd be happy with.
>
> I mentioned it in other subthreads a few times:   only arithmetic
> operations for scalar types.
>
> The restriction to "scalar" types is meant to include complex numbers,
> or even quaternions, but not vectors or matrices(in the mathematical
> sense).  If we added vectors, then the semantics of add and
> multiplication would become ambiguous.  (piecewise adding or
> concatenating; cross-product or scalar product;...)
>
> *: I agree on the restriction to numeric types.  I wouldn't exclude
> other ops, like % on BigIntegers or other ops on other classes if it
> made mathemtical sense for them.

I think it better to accept that Java isn't the first choice of language to 
do vector and matrix processing in, and just settle for dot() and cross() 
and det() methods. Complex numbers, well, that's been discussed often 
enough - the only thing that would make me happy is a primitive "complex" 
data type, a la

complex pos = 1.0 + 3*I;

AHS 

Arved Sandstrom wrote:
> Complex numbers, well, that's been discussed often 
> enough - the only thing that would make me happy is a primitive "complex" 
> data type, a la
> 
> complex pos = 1.0 + 3*I; // Except with a capital 'C' - Lew

I see you assume the

import static java.math.Complex.I;

I see a tension between the unreadability of the short name and the natural 
expression of the normal mathematical notation.

Those that feel short names are anathema undoubtedly will eschew that import 
static, but it remains available for those who feel that they can read normal 
maths notation just fine, thank you.

I wonder if Complex.J should be provided as a synonym, for those who follow 
that notation.

-- 
Lew

Andreas Leitgeb wrote:
> I do not propose using brackets for anything else than arrays, 
> but that should not stop me from discussing it anyway:
> 
>>    Set<Integer> sieve = //...
>>    sieve[2] = // ...??
>>    if( sieve[3] )

I don't think anyone would propose an index notation for a type that does not 
implement java.util.RandomAccess and is not a Map.

-- 
Lew

Arved Sandstrom <asandstrom@accesswave.ca> wrote:
> I think it better to accept that Java isn't the first choice of language to 
> do vector and matrix processing in, and just settle for dot() and cross() 
> and det() methods.

Yes! Otherwise this would remind me of APL :-)

> Complex numbers, well, that's been discussed often enough -
> the only thing that would make me happy is a primitive "complex" 
> data type, a la
> complex pos = 1.0 + 3*I;

I wonder about how you'd expect it to be implemented.
One could think of a bytecode-prefix (like "wide") that would turn
following primitive-arithmetics to according complex arithmetics,
or the compiler could do the job of dealing with two doubles at 
bytecode level that together make a complex.

I do not think that complex numbers are used *so* often, that 
either of these would be justified, but I do think that BigInteger
and BigDecimal are going to be more and more used, justifying a
new drift of using certain operators on certain classes, from 
which a plain normal Complex class could also benefit.

If complex were made a primitive, there'd be a way to indicate
that a certain literal was meant as a complex literal, even if 
its imaginary part happens to be zero.
(3+0i)   could be such a literal, with "i" being a token just
like "L" is for "long" literals. To make the value of a double
variable an imaginary part, one would do:  real + imag*1i
But that's just playing with thoughts, not serious.

Mark Thornton wrote:
> Wojtek wrote:
>> Mark Thornton wrote :
>>> Wojtek wrote:
>>>> Patricia Shanahan wrote :
>>>>> The challenge I presented earlier in this thread is a *very* simple
>>>>> example of a mathematical formula:
>>>>>
>>>>> "Consider calculating the sum of the first n terms of an arithmetic
>>>>> series, given its first term, a1, and common difference, d.
>>>>> http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29 
>>>>>
>>>>>
>>>>>
>>>>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."
>>>>>
>>>>> Can you produce a descriptive method name form of this expression that
>>>>> is as obviously equivalent to the original formula?
>>>>
>>>> Ok, this appears to be used as a utility method, therefore I would 
>>>> make it static with the method returning the result of the formulae 
>>>> calculation. The class could be named MyMath. So:
>>>>
>>>> BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
>>>> termLimit, difference);
>>>>
>>>
>>> I think you have missed the point. It is just a fragment of code and 
>>> we don't want to turn every such fragment into a method of its own. 
>>> It is also on the very simple end of mathematical expressions.
>>
>> Also to Patricia,
>>
>> The series sum is a pure math operation, and would not need operator 
>> overloading.
>>
>> And yes, I WOULD create a library with these types of calls. It makes 
>> using them in multiple places consistent. I would encase it even for a 
>> single use as it makes cleaner code at the point of usage.
>>
>> What the formula is like in the method is up to the author. Black box 
>> testing should prove that the formula implementation is correct. If 
>> you do not have trust in the author, then extend the library class and 
>> override the method with your own implementation.
>>
>> But that is always the risk in using someone elses library for 
>> everything from high math formula to common string operations. The 
>> assumption is that it works until proven false. If you are using the 
>> library for mission critical use (life critical, million dollar 
>> critical) then you would perform extensive testing before it was trusted.
>>
>> Maybe I am missing the point with this series sum formula. It just 
>> seems obvious to me to encase it in a method, prove it, then just use it.
> 
> I think that James Gosling has observed that people who are not 
> mathematicians/engineers almost invariably miss the point with regard to 
> the desireability of operator overloading at least for complex 
> arithmetic. In part I think it is the expression itself, in STANDARD 
> form, which is recognised, not the name which you might give it. Others 
> have said that the language of mathematicians is not 
> English/French/German or any other natural language but symbolic with 
> centuries of history. Its representation in software is necessarily 
> approximate, but words are not the answer. Or at least not the answer 
> desired by mathematicians.
> Does forcing the use of words make the result more comprehensible to non 
> mathematicians? In my experience the answer is no, the code remains as 
> black box as ever to those without sufficient maths background.

And it's even worse with methodwise syntax instead of functionwise. That is:

     b.exp(2).minus(4.times(a).times(c))

is even worse for a mathematician than

     minus(exp(b, 2), times(times(4, a), c))


-- 
John W. Kennedy
  "Those in the seat of power oft forget their failings and seek only 
the obeisance of others!  Thus is bad government born!  Hold in your 
heart that you and the people are one, human beings all, and good 
government shall arise of its own accord!  Such is the path of virtue!"
   -- Kazuo Koike.  "Lone Wolf and Cub:  Thirteen Strings" (tr. Dana Lewis)

Patricia Shanahan wrote:
> Without programmer defined operator overloading, the language has to
> define all the arithmetic types. Currently, it is missing, as language
> features, complex (based on each of float and double), rational, and
> interval arithmetic.

> Of those, complex is the most basic and essential. Fortran has supported
> it, as the equivalent of a Java primitive type, for decades.

I suppose the IEEE-754r types (16 and 128 binary, 32, 64, and 128 
decimal) are in the Java pipeline, too?
-- 
John W. Kennedy
  "The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
   -- Charles Williams.  "Mount Badon"

Wojtek wrote:
> Patricia Shanahan wrote :
>> I actually strongly agree with this. The place where we differ is that I
>> feel that "+" is the most descriptive, clearest symbol possible for
>> arithmetic addition. Using it for anything else, including String
>> concatenation, is just as bad as using a misleading method name.
> 
> Yes.
> 
> And the people at PHP agree with that as PHP string concatination is 
> done with a period.
> 
> It is too late to do anything about it though. Think of the millions of 
> LOC that would be affected...

Maybe it's because I ran into group theory at a very early age, but I 
just don't have any problem with "+" for concatenation. Languages that 
do not use "+" for concatenation, in fact, generally do so because they 
have free-and-easy conversion, and "123" + "456" is already defined as 
resulting in 579.


-- 
John W. Kennedy
  Having switched to a Mac in disgust at Microsoft's combination of 
incompetence and criminality.

Andreas Leitgeb wrote:
> Mark Space <markspace@sbc.global.net> wrote:
>> "length" confuses me because it's not an operator.  Also I don't see 
>> much readability difference between "length" and "length()".  (Or 
>> "size()" for that matter.)
> 
> arrays are just too different from Collections.
> If I could pass an array to a function taking e.g. a List,
> then the array would need to have real methods, that implement
> the interface's methods. This also breaks with arrays of primitive
> types.  I don't think, this is a good way to go.

Good points also.  I think I have to agree.

Andreas Leitgeb wrote:
> Arved Sandstrom <asandstrom@accesswave.ca> wrote:
>> I think it better to accept that Java isn't the first choice of language to 
>> do vector and matrix processing in, and just settle for dot() and cross() 
>> and det() methods.
> 
> Yes! Otherwise this would remind me of APL :-)
> 
>> Complex numbers, well, that's been discussed often enough -
>> the only thing that would make me happy is a primitive "complex" 
>> data type, a la
>> complex pos = 1.0 + 3*I;
> 
> I wonder about how you'd expect it to be implemented.
> One could think of a bytecode-prefix (like "wide") that would turn
> following primitive-arithmetics to according complex arithmetics,
> or the compiler could do the job of dealing with two doubles at 
> bytecode level that together make a complex.
> 
> I do not think that complex numbers are used *so* often, that 

I suppose that depends on how you are counting. Complex numbers are 
extremely common in engineering and physics.

Mark Thornton

Lew wrote:
> Joshua Cranmer wrote:
>> To me, the presence of a pseudo-variable `.length' feels as if it 
>> could be modifiable. I'm not heavily committed one way or the other on 
>> overloading `.length', although I would probably rather see an array 
>> get a .size() or .isEmpty() "function" instead.
> 
> Given the existence of the 'final' keyword, even a real, non-pseudo 
> instance variable could be non-modifiable.  Why shouldn't 'length' be 
> immutable?
> 

But a `final' variable can only be changed once. So the invariant:

ComplexObject o = new ComplexObject();
int cache = o.someFinalVariable;
o.doCrazyMutation();
assert (o.someFinalVariable == cache);

will always remain true, whereas the `length' pseudo-variable wouldn't 
have this same invariant. At best, it's a minor point, but overloading 
`.length' doesn't quite feel right to me.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On Wed, 14 May 2008, John W Kennedy wrote:

> Wojtek wrote:
>> Patricia Shanahan wrote :
>>> I actually strongly agree with this. The place where we differ is that I
>>> feel that "+" is the most descriptive, clearest symbol possible for
>>> arithmetic addition. Using it for anything else, including String
>>> concatenation, is just as bad as using a misleading method name.
>> 
>> Yes.
>> 
>> And the people at PHP agree with that as PHP string concatination is done 
>> with a period.
>> 
>> It is too late to do anything about it though. Think of the millions of LOC 
>> that would be affected...
>
> Maybe it's because I ran into group theory at a very early age, but I just 
> don't have any problem with "+" for concatenation.

I probably don't need to point out that strings aren't a group under 
concatenation! If i've got my terminology right, they're a monoid - you've 
got a (infinite) set and an operator that's closed over the set, the 
operator is associative, and there's an identity element (""). But there 
are no inverses, so it's not a group. Not that this has anything to do 
with the suitability of + for concatenation, of course. I mention it 
merely out of geekhood.

> Languages that do not use "+" for concatenation, in fact, generally do 
> so because they have free-and-easy conversion, and "123" + "456" is 
> already defined as resulting in 579.

As a minor counterexample, in smalltalk, , is the concatenation operator, 
for arrays as well as strings, i think. I don't think + is defined on 
strings, BICBW - i don't have any smalltalk docs to hand.

FWIW, i'm also perfectly happy with + for string concatenation.

tom

-- 
THE DRUMMER FROM DEF LEPPARD'S ONLY GOT ONE ARM!

Wojtek wrote:
> Using descriptive method names leaves no ambiguity as to what will 
> happen, whereas with operator overloading you need to make a best 
> "guess" at what the writer meant by the operator he/she chose for an 
> operation.

I think +-*/ is just as clear as add subtract multiply divide.

> Yes, I have written in C++, and yes I have used operator overloading. 
> Unless you and the writer are in the same mind-set the only way to 
> ferret out what is happening is to dig into the source code.

You read the docs or the code.

Exact same thing as with Java code.

It is no more difficult to have a method shift do IO than to have a <<
operator do IO.

No difference.

Arne

PS: I am not really for operator overloading in Java - I am for keeping
     the language as simple as possible. But readability would not be
     my argument against operator overloading.

Mark Space wrote:
> Wojtek wrote:
>> Ok, this appears to be used as a utility method, therefore I would 
>> make it static with the method returning the result of the formulae 
>> calculation. The class could be named MyMath. So:
>>
>> BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm, 
>> termLimit, difference);
> 
> Oops.  That was actually a really good answer. :)

But not to the question asked.

It just moves the problem from the original code to the
new utility code.

Arne

Daniel Dyer wrote:
> I agree.  On my last project I had to deal with a whole load of 
> calculations that used BigDecimals, and they were a nightmare to maintain.

I agree that if you are doing math stuff, then operator overloading
will make the code much easier to read.

BigDecimal or Complex or whatever numeric class.

But if we add to the language every time a special niche of usage
has a requirement, then we will be recreating PL/I or Ada.

I don't think that is a good idea.

Arne

Arne Vajh�j wrote:
> Mark Space wrote:
>> Oops.  That was actually a really good answer. :)
> 
> But not to the question asked.
> 
> It just moves the problem from the original code to the
> new utility code.

True, as later discussion revealed.

However, anytime you have an algorithm which may be less that 100% 
clear, "document" and "test" are always appropriate answers.  Operator 
overloading won't change that.

Mathematicians are famous for a kind of lack of documentation with 
formulas.  The programming discipline only places a brighter light on 
this issue.


Joke going around the college I attended:

A physics professor is lecturing and writes a problem equation on the 
blackboard, then he writes the solution.  "The derivation of this answer 
is obvious" he says.  Then he pauses, and turns towards the blackboard 
to review his equations.  "Or is it?" he ponders out-loud and promptly 
dismisses class.

A day goes by and the class remains dismissed.

After a second day and a notice is posted saying that class will again 
be skipped.

After a third day his students grow very concerned for his health as 
class is still suspended.

Finally on the fourth day class is reconvening.  The professor enters 
the room and re-writes the equations on the blackboard.  "Yes, it was 
obvious" he announces, and continues the lecture from the point he left off.

Mark Space wrote:
> However, anytime you have an algorithm which may be less that 100% 
> clear, "document" and "test" are always appropriate answers.  Operator 
> overloading won't change that.

True. But explaining the the syntax used in the code should not be
necessary.

// multiply x with 2
x = 2 * x;

and

// multiply x with 2
x = x.multiply(2);

are both rather useless.

What should be documented is why multiply with 2.

Arne

Joshua Cranmer wrote:
> But a `final' variable can only be changed once. So the invariant:

A 'final' instance variable cannot be changed at all.  Not even once.  If it 
is not assigned, the class won't compile.  That assignment is its initial 
value, not a changed one.

> ComplexObject o = new ComplexObject();
> int cache = o.someFinalVariable;
> o.doCrazyMutation();
> assert (o.someFinalVariable == cache);
> 
> will always remain true, whereas the `length' pseudo-variable wouldn't 

'length' is not a pseudo-variable, it's a variable.

> have this same invariant. 

And I missed this point - I just don't understand what you mean.

If you do

int cache = someArray.length;

doCrazyMutation( someArray );

then

assert cache == someArray.length;

will still hold.

-- 
Lew

"Lew" <lew@lewscanon.com> wrote in message 
news:I_GdnRdv2KtXR7fVnZ2dnUVZ_oSunZ2d@comcast.com...
> Arved Sandstrom wrote:
>> Complex numbers, well, that's been discussed often enough - the only 
>> thing that would make me happy is a primitive "complex" data type, a la
>>
>> complex pos = 1.0 + 3*I; // Except with a capital 'C' - Lew
>
> I see you assume the
>
> import static java.math.Complex.I;
>
> I see a tension between the unreadability of the short name and the 
> natural expression of the normal mathematical notation.
>
> Those that feel short names are anathema undoubtedly will eschew that 
> import static, but it remains available for those who feel that they can 
> read normal maths notation just fine, thank you.
>
> I wonder if Complex.J should be provided as a synonym, for those who 
> follow that notation.
>
> -- 
> Lew

I read one paper where along with the syntax above ("complex" as a primitive 
type) 'I' was proposed as a keyword. Provided that it's a contextual keyword 
I have no real problem with that. As far as it being 'I' or 'J' or 'i' or 
'j', well, I figure if one can be implemented then four will not be more of 
a problem. I myself could live with just one - I had to keep mentally 
switching between them in school anyway (I am used to the lowercase forms).

AHS 

"Arne Vajh�j" <arne@vajhoej.dk> wrote in message 
news:482b9c9c$0$90272$14726298@news.sunsite.dk...
> Mark Space wrote:
>> However, anytime you have an algorithm which may be less that 100% clear, 
>> "document" and "test" are always appropriate answers.  Operator 
>> overloading won't change that.
>
> True. But explaining the the syntax used in the code should not be
> necessary.
>
> // multiply x with 2
> x = 2 * x;
>
> and
>
> // multiply x with 2
> x = x.multiply(2);
>
> are both rather useless.
>
> What should be documented is why multiply with 2.
>
> Arne

To double it?

.....running for cover.....

AHS 

Lew <lew@lewscanon.com> wrote:
>> ComplexObject o = new ComplexObject();
>> int cache = o.someFinalVariable;
>> o.doCrazyMutation();
>> assert (o.someFinalVariable == cache);

>> will always remain true, whereas the `length' pseudo-variable wouldn't 
>> have this same invariant. 
> And I missed this point - I just don't understand what you mean.

Doesn't matter that much.  The context was about using a ".length"
postfix-operator for collections, for which that wouldn't have 
behaved neither like a normal field nor like a final.  But it's a bad
idea, anyway, so lets just forget it.

John W Kennedy wrote:
> And it's even worse with methodwise syntax instead of functionwise. That 
> is:
> 
>     b.exp(2).minus(4.times(a).times(c))
> 
> is even worse for a mathematician than
> 
>     minus(exp(b, 2), times(times(4, a), c))

Why would a mathematician waste their time writing Java code?

-- 
Lew

Lew wrote:
> John W Kennedy wrote:
>> And it's even worse with methodwise syntax instead of functionwise. 
>> That is:
>>
>>     b.exp(2).minus(4.times(a).times(c))
>>
>> is even worse for a mathematician than
>>
>>     minus(exp(b, 2), times(times(4, a), c))
> 
> Why would a mathematician waste their time writing Java code?
> 

Because there isn't a perfect language.

Mark Thornton

On May 15, 2:22 pm, Mark Thornton <mthorn...@optrak.co.uk> wrote:
> Lew wrote:
> > John W Kennedy wrote:
> >> And it's even worse with methodwise syntax instead of functionwise.
> >> That is:
>
> >>     b.exp(2).minus(4.times(a).times(c))
>
> >> is even worse for a mathematician than
>
> >>     minus(exp(b, 2), times(times(4, a), c))
>
> > Why would a mathematician waste their time writing Java code?
>
> Because there isn't a perfect language.
>
> Mark Thornton

Would Java's fastidious specification of the details of numerical
computations might make it a language of choice for someone interested
in numerical analysis?  Java's commitment to replicability of results
seems like something that would appeal to the mathematical mindset.

Going back a little closer to the original topic of the thread, I'm
interested in how different people pick different classes that they
think are the place that operator overloading is really necessary.
For me the real win would be if I could overload array operations on
arrays of primitive numerics.  Of course it doubtless depends on what
you are used to, and I spend a lot of time coding in IDL where array
operations are critical to efficiency.  I would love to be able to
say:

    int[] x;
    float[] y;
    double[] z;
    double a;
    ...
    z = a*x*y;


with a access violation if the bounds don't agree.

It would have made the main Java project I've been working on for the
past 5 years much easier.

    Regards,
    Tom McGlynn

Arved Sandstrom wrote:
> "Arne Vajh�j" <arne@vajhoej.dk> wrote in message 
> news:482b9c9c$0$90272$14726298@news.sunsite.dk...
>> Mark Space wrote:
>>> However, anytime you have an algorithm which may be less that 100% clear, 
>>> "document" and "test" are always appropriate answers.  Operator 
>>> overloading won't change that.
>> True. But explaining the the syntax used in the code should not be
>> necessary.
>>
>> // multiply x with 2
>> x = 2 * x;
>>
>> and
>>
>> // multiply x with 2
>> x = x.multiply(2);
>>
>> are both rather useless.
>>
>> What should be documented is why multiply with 2.
> 
> To double it?
> 
> ....running for cover.....

A couple of 15 inch shells heading in your direction ...

Arne

Tom McGlynn wrote:
> On May 15, 2:22 pm, Mark Thornton <mthorn...@optrak.co.uk> wrote:
>> Lew wrote:
>>> John W Kennedy wrote:
>>>> And it's even worse with methodwise syntax instead of functionwise.
>>>> That is:
>>>>     b.exp(2).minus(4.times(a).times(c))
>>>> is even worse for a mathematician than
>>>>     minus(exp(b, 2), times(times(4, a), c))
>>> Why would a mathematician waste their time writing Java code?
>> Because there isn't a perfect language.
> 
> Would Java's fastidious specification of the details of numerical
> computations might make it a language of choice for someone interested
> in numerical analysis?  Java's commitment to replicability of results
> seems like something that would appeal to the mathematical mindset.

Java attitude towards precision would be considered an advantage
by some and a disadvantage (performance) by other doing numerical
analysis.

But few mathematicians are interested in numerical analysis.

Other sciences are more oriented towards it.

Arne

Mark Thornton wrote:
> Lew wrote:
>> John W Kennedy wrote:
>>> And it's even worse with methodwise syntax instead of functionwise. 
>>> That is:
>>>
>>>     b.exp(2).minus(4.times(a).times(c))
>>>
>>> is even worse for a mathematician than
>>>
>>>     minus(exp(b, 2), times(times(4, a), c))
>>
>> Why would a mathematician waste their time writing Java code?
>>
> 
> Because there isn't a perfect language.

What I mean is why would a mathematician waste their time writing any code in 
any computer language?

-- 
Lew

Lew wrote:
> Mark Thornton wrote:
>> Lew wrote:
>>> John W Kennedy wrote:
>>>> And it's even worse with methodwise syntax instead of functionwise. 
>>>> That is:
>>>>
>>>>     b.exp(2).minus(4.times(a).times(c))
>>>>
>>>> is even worse for a mathematician than
>>>>
>>>>     minus(exp(b, 2), times(times(4, a), c))
>>>
>>> Why would a mathematician waste their time writing Java code?
>>>
>>
>> Because there isn't a perfect language.
> 
> What I mean is why would a mathematician waste their time writing any 
> code in any computer language?
> 

We gave up the rooms full of human 'calculators' some time ago! :-)

Mark Thornton

Lew wrote:
> Mark Thornton wrote:
>> Lew wrote:
>>> John W Kennedy wrote:
>>>> And it's even worse with methodwise syntax instead of functionwise. 
>>>> That is:
>>>>
>>>>     b.exp(2).minus(4.times(a).times(c))
>>>>
>>>> is even worse for a mathematician than
>>>>
>>>>     minus(exp(b, 2), times(times(4, a), c))
>>>
>>> Why would a mathematician waste their time writing Java code?
>>
>> Because there isn't a perfect language.
> 
> What I mean is why would a mathematician waste their time writing any 
> code in any computer language?

Same reason programmers grow rhododendron in their garden ??

Actually I believe a few mathematicians are using computers
to create proofs.

But that will be far far from numerical calculations.

Arne

Lew wrote:
>> What I mean is why would a mathematician waste their time writing any 
>> code in any computer language?

Mark Thornton wrote:
> We gave up the rooms full of human 'calculators' some time ago! :-)

Funny, but not related to math.

-- 
Lew

Lew wrote:
> Lew wrote:
>>> What I mean is why would a mathematician waste their time writing any 
>>> code in any computer language?
> 
> Mark Thornton wrote:
>> We gave up the rooms full of human 'calculators' some time ago! :-)
> 
> Funny, but not related to math.
> 

Why not? A lot of mathematicians need to produce numerical answers, not
just theoretical proofs.

Patricia

Lew wrote:
> Lew wrote:
>>> What I mean is why would a mathematician waste their time writing any 
>>> code in any computer language?
> 
> Mark Thornton wrote:
>> We gave up the rooms full of human 'calculators' some time ago! :-)
> 
> Funny, but not related to math.
> 

Do you know that some Victorian mathematicians did employ rooms full of 
people to perform calculations? I am an applied mathematician, so it is 
not enough to produce nice proofs, useful results are also necessary and 
these often require significant computation.

Mark Thornton

Arne Vajh�j wrote:
> 
> But few mathematicians are interested in numerical analysis.
> 

I suppose that depends on how you classify mathematicians. Many applied 
mathematicians are very much concerned about the numerical stability and 
accuracy of their computations.

Mark Thornton

Mark Thornton wrote:
> Arne Vajh�j wrote:
>> But few mathematicians are interested in numerical analysis.
> 
> I suppose that depends on how you classify mathematicians. Many applied 
> mathematicians are very much concerned about the numerical stability and 
> accuracy of their computations.

My understanding of math is that it is all about going from axioms
to theorems and that numbers always are exact.

And that the dirty world of floating point calculations is
left to the sciences that has some real world numbers they need to
crunch.

But then I am not a mathematician, so I can be 110% wrong ...

Arne

Arne Vajh�j wrote:
> Mark Thornton wrote:
>> Arne Vajh�j wrote:
>>> But few mathematicians are interested in numerical analysis.
>>
>> I suppose that depends on how you classify mathematicians. Many 
>> applied mathematicians are very much concerned about the numerical 
>> stability and accuracy of their computations.
> 
> My understanding of math is that it is all about going from axioms
> to theorems and that numbers always are exact.
> 
> And that the dirty world of floating point calculations is
> left to the sciences that has some real world numbers they need to
> crunch.
> 
It is a matter of naming really and it varies from university to 
university. My first degree was in mathematics (pure and applied), I 
then did an honours year nominally in applied maths, followed by a PhD 
which was in an engineering faculty. I consider myself to be an applied 
mathematician, which means I am familiar with aspect of physics, 
chemistry and engineering.

Mark Thornton

Arne Vajh�j wrote:
> Mark Thornton wrote:
>> Arne Vajh�j wrote:
>>> But few mathematicians are interested in numerical analysis.
>>
>> I suppose that depends on how you classify mathematicians. Many 
>> applied mathematicians are very much concerned about the numerical 
>> stability and accuracy of their computations.
> 
> My understanding of math is that it is all about going from axioms
> to theorems and that numbers always are exact.

That is part of mathematics, but not the whole story. Understanding the
results and applying them to real world situations is also important.

Patricia

On May 16, 8:52 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> Lew wrote:
> > Mark Thornton wrote:
> >> Lew wrote:
> >>> John W Kennedy wrote:
> >>>> And it's even worse with methodwise syntax instead of functionwise.
> >>>> That is:
>
> >>>>     b.exp(2).minus(4.times(a).times(c))
>
> >>>> is even worse for a mathematician than
>
> >>>>     minus(exp(b, 2), times(times(4, a), c))
>
> >>> Why would a mathematician waste their time writing Java code?
>
> >> Because there isn't a perfect language.
>
> > What I mean is why would a mathematician waste their time writing any
> > code in any computer language?
>
> Same reason programmers grow rhododendron in their garden ??
>
> Actually I believe a few mathematicians are using computers
> to create proofs.
>
> But that will be far far from numerical calculations.
>
> Arne


This is a fairly narrow view of mathematics and what mathematicians
do.  My understanding is that the single largest employer of
mathematicians in the world is the National Security Agency where
there's a lot of work where Java's BigIntegers and such could play a
significant role.  Similarly, a lot (compared to the total population
of mathematicians at least!) of mathematicians now work on Wall Street
in the analysis of markets -- I believe more than in academics.

Even if we limit ourselves to academic mathematics, fields like the
development of chaotic systems and fractal analysis of images are of
immense interest in both pure and applied mathemetics and there are
plenty of other areas where numerical computations play a major role.

There's a lot more to mathematics than abstract proofs.

Tom McGlynn wrote:
> On May 16, 8:52 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
>> Lew wrote:
>>> Mark Thornton wrote:
>>>> Lew wrote:
>>>>> John W Kennedy wrote:
>>>>>> And it's even worse with methodwise syntax instead of functionwise.
>>>>>> That is:
>>>>>>     b.exp(2).minus(4.times(a).times(c))
>>>>>> is even worse for a mathematician than
>>>>>>     minus(exp(b, 2), times(times(4, a), c))
>>>>> Why would a mathematician waste their time writing Java code?
>>>> Because there isn't a perfect language.
>>> What I mean is why would a mathematician waste their time writing any
>>> code in any computer language?
>> Same reason programmers grow rhododendron in their garden ??
>>
>> Actually I believe a few mathematicians are using computers
>> to create proofs.
>>
>> But that will be far far from numerical calculations.
>>
>> Arne
> 
> 
> This is a fairly narrow view of mathematics and what mathematicians
> do.  My understanding is that the single largest employer of
> mathematicians in the world is the National Security Agency where
> there's a lot of work where Java's BigIntegers and such could play a
> significant role.  Similarly, a lot (compared to the total population
> of mathematicians at least!) of mathematicians now work on Wall Street
> in the analysis of markets -- I believe more than in academics.
> 
> Even if we limit ourselves to academic mathematics, fields like the
> development of chaotic systems and fractal analysis of images are of
> immense interest in both pure and applied mathemetics and there are
> plenty of other areas where numerical computations play a major role.
> 
> There's a lot more to mathematics than abstract proofs.

I mean, instead of hiring someone who knows how to write software.  I am not 
questioning the value of software in mathematics, I am questioning the value 
of software written by mathematicians.

-- 
Lew

"Lew" <lew@lewscanon.com> wrote in message 
news:9uWdnQ_7EJTo9rLVnZ2dnUVZ_vadnZ2d@comcast.com...
> Tom McGlynn wrote:
[ SNIP ]
>> This is a fairly narrow view of mathematics and what mathematicians
>> do.  My understanding is that the single largest employer of
>> mathematicians in the world is the National Security Agency where
>> there's a lot of work where Java's BigIntegers and such could play a
>> significant role.  Similarly, a lot (compared to the total population
>> of mathematicians at least!) of mathematicians now work on Wall Street
>> in the analysis of markets -- I believe more than in academics.
>>
>> Even if we limit ourselves to academic mathematics, fields like the
>> development of chaotic systems and fractal analysis of images are of
>> immense interest in both pure and applied mathemetics and there are
>> plenty of other areas where numerical computations play a major role.
>>
>> There's a lot more to mathematics than abstract proofs.
>
> I mean, instead of hiring someone who knows how to write software.  I am 
> not questioning the value of software in mathematics, I am questioning the 
> value of software written by mathematicians.
> -- 
> Lew

In the above case someone who knows mathematics *and* knows how to write 
software. By "someone who knows mathematics" I don't mean someone who is 
doing groundbreaking research but a student with a solid maths background 
(at a level relevant to the actual problem domain). For a sufficiently 
complex problem to code up the programmer is going to need the background of 
a grad student or a ... mathematician.

This happens in every problem domain. A lot of programmers are good at 
programming, they just don't know very many (if any) problem domains all 
that well. This includes graphics design, let alone business or science or 
finance or engineering or law or medicine or mathematics. But a lot of 
potential employers who require software do need their coders to know a 
specific field quite well. So they can't tap into the large general field of 
programmers, they need either programmers with a solid academic/work 
background in a given field, or they need professionals in a field who also 
know how to code.

As an example, back in the mid-90's I did a certain amount of scientific 
programming related to supporting various oceanographic contracts of 
individual researchers. I (and the other programmers similarly employed by 
other scientists) invariably had at least BSc degrees in physics or 
chemistry or whatever, and much (if not most) of our value derived from the 
fact that the scientist didn't have to stupid down his requests and 
comments. The typical CS grad would have had heavy weather of those jobs.

As another example, your usual bioinformatics programmer doesn't typically 
have a CS degree - they have biology and/or chemistry and _then_ they have 
programming skills. And of course the list goes on and on - not every 
programming job out there is about Web 2.0 and RoR and J2EE.

And correct me if I'm wrong, but the people coding up Maple and Mathematica 
and Matlab and various scientific/engineering/mathematical libraries etc are 
not exactly CS types - they are mathematicians and scientists and engineers 
first, coders second.

Hiring someone who knows how to write software, yes. But they also need to 
be knowledgeable in the problem domain, so at that point it's sort of moot 
whether you describe the person as an engineer who can code or a coder who 
knows engineering. But for a complex mathematical application the person 
will almost certainly not be a programmer with a couple of first year 
calculus classes.

AHS 

Arved Sandstrom wrote:
> Hiring someone who knows how to write software, yes. But they also need to 
> be knowledgeable in the problem domain, so at that point it's sort of moot 
> whether you describe the person as an engineer who can code or a coder who 
> knows engineering. But for a complex mathematical application the person 
> will almost certainly not be a programmer with a couple of first year 
> calculus classes.

Excellent points.

-- 
Lew

Lew wrote:
> not questioning the value of software in mathematics, I am questioning 
> the value of software written by mathematicians.
> 

The financial value is substantial. The software used in areas such as 
weather forecasting, (petroleum) reservoir engineering, (financial) 
market trading, and may others will have had substantial contributions 
from mathematicians.

Mark Thornton

Arved Sandstrom wrote:
> comments. The typical CS grad would have had heavy weather of those jobs.

The typical CS graduate often seems to have no understanding of 'float' 
and 'double', often to the point of wanting to eliminate these types 
from the language. At the university where I did my undergrad degree, CS 
students were offered some modules in numerical analysis, but I seem to 
remember that they were not too popular. I did do them, and a few 
straight CS modules as well such as one on Simula 67.

Mark Thornton

"Mark Thornton" <mthornton@optrak.co.uk> wrote in message 
news:4zRXj.14121$Pp2.5721@newsfe10.ams2...
> Lew wrote:
>> not questioning the value of software in mathematics, I am questioning 
>> the value of software written by mathematicians.
>>
>
> The financial value is substantial. The software used in areas such as 
> weather forecasting, (petroleum) reservoir engineering, (financial) market 
> trading, and may others will have had substantial contributions from 
> mathematicians.
>
> Mark Thornton

Or more generally, not just mathematicians but mathematical 
scientists/engineers etc. That is to say, pure mathematicians will probably 
be mathematicians. But applied mathematicians will probably not be (my 
guess).

To use one of your examples - weather forecasting (well, atmospheric 
science/oceanography) - most people in the field will not have math (at any 
level) as a formal degree. If they do, it's probably as an undergrad. But 
they do have stupendous amounts of math.

AHS 

Arved Sandstrom wrote:
> To use one of your examples - weather forecasting (well, atmospheric 
> science/oceanography) - most people in the field will not have math (at any 
> level) as a formal degree. If they do, it's probably as an undergrad. But 
> they do have stupendous amounts of math.

It most certainly is not an exact science ...

:-)

Arne

Mark Thornton wrote:
> Lew wrote:
>> not questioning the value of software in mathematics, I am questioning 
>> the value of software written by mathematicians.
>>
> 
> The financial value is substantial. The software used in areas such as 
> weather forecasting, (petroleum) reservoir engineering, (financial) 
> market trading, and may others will have had substantial contributions 
> from mathematicians.

More generally, a lot scientific and engineering software is written in
layers. The building blocks are subject neutral implementations of
mathematical concepts, such as matrix factorizations. Writing some of
those building blocks with good numerical properties involves
non-trivial mathematics.

Patricia

Arved Sandstrom wrote:
> "Mark Thornton" <mthornton@optrak.co.uk> wrote in message 
> news:4zRXj.14121$Pp2.5721@newsfe10.ams2...
>> Lew wrote:
>>> not questioning the value of software in mathematics, I am questioning 
>>> the value of software written by mathematicians.
>>>
>> The financial value is substantial. The software used in areas such as 
>> weather forecasting, (petroleum) reservoir engineering, (financial) market 
>> trading, and may others will have had substantial contributions from 
>> mathematicians.
>>
>> Mark Thornton
> 
> Or more generally, not just mathematicians but mathematical 
> scientists/engineers etc. That is to say, pure mathematicians will probably 
> be mathematicians. But applied mathematicians will probably not be (my 
> guess).
> 
> To use one of your examples - weather forecasting (well, atmospheric 
> science/oceanography) - most people in the field will not have math (at any 
> level) as a formal degree. If they do, it's probably as an undergrad. But 
> they do have stupendous amounts of math.

http://www.sheffield.ac.uk/geography/staff/bigg_grant/

I did the same undergraduate and honours degrees at the University of 
Adelaide.

Mark Thornton

"Mark Thornton" <mthornton@optrak.co.uk> wrote in message 
news:IAYXj.19824$4B6.5035@newsfe14.ams2...
> Arved Sandstrom wrote:
>> "Mark Thornton" <mthornton@optrak.co.uk> wrote in message 
>> news:4zRXj.14121$Pp2.5721@newsfe10.ams2...
>>> Lew wrote:
>>>> not questioning the value of software in mathematics, I am questioning 
>>>> the value of software written by mathematicians.
>>>>
>>> The financial value is substantial. The software used in areas such as 
>>> weather forecasting, (petroleum) reservoir engineering, (financial) 
>>> market trading, and may others will have had substantial contributions 
>>> from mathematicians.
>>>
>>> Mark Thornton
>>
>> Or more generally, not just mathematicians but mathematical 
>> scientists/engineers etc. That is to say, pure mathematicians will 
>> probably be mathematicians. But applied mathematicians will probably not 
>> be (my guess).
>>
>> To use one of your examples - weather forecasting (well, atmospheric 
>> science/oceanography) - most people in the field will not have math (at 
>> any level) as a formal degree. If they do, it's probably as an undergrad. 
>> But they do have stupendous amounts of math.
>
> http://www.sheffield.ac.uk/geography/staff/bigg_grant/
>
> I did the same undergraduate and honours degrees at the University of 
> Adelaide.
>
> Mark Thornton

He's not a bad example, although he took on rather more formal math than 
most of the people I know in geophysics (I am not a geophysicist myself 
:-)).

He had rather a distinguished mentor there for a while I see...Adrian Gill. 
I have the latter's "Atmosphere-Ocean Dynamics".

AHS 

Arved Sandstrom wrote:
> "Mark Thornton" <mthornton@optrak.co.uk> wrote in message 
> news:IAYXj.19824$4B6.5035@newsfe14.ams2...
>> Arved Sandstrom wrote:
> 
> He's not a bad example, although he took on rather more formal math than 
> most of the people I know in geophysics (I am not a geophysicist myself 
> :-)).

There were 5 of us who completed our maths honours degrees (all first 
class) at the end of 1979. Perhaps I should track down the other three 
and see what they are up to now.

Mark Thornton

Arved Sandstrom wrote:
> "Tom Anderson" <twic@urchin.earth.li> wrote in message 
> news:Pine.LNX.4.64.0805101428000.24915@urchin.earth.li...
>> On Sat, 10 May 2008, Thomas Schodt wrote:
>>
> [ SNIP ]
>>> With named methods people are more likely to make up a new name that 
>>> better describes what the method does.
>> I see absolutely no reason to believe that to be the case.
>>
>> tom
> 
> Nor do I - it depends entirely on the programmer.

I can only describe what I perceive to be the case,
but based on the C++ and C code I have encountered
over a decade, there is a definite trend.

Arne Vajh�j wrote :
> I am not really for operator overloading in Java - I am for keeping
>      the language as simple as possible. But readability would not be
>      my argument against operator overloading.

But readability is at the root of the argument.

Proponents hang their entire case around readability, whereas opponents 
point to potential obstification.

-- 
Wojtek :-)

Wojtek wrote:
> Arne Vajh�j wrote :
>> I am not really for operator overloading in Java - I am for keeping
>>      the language as simple as possible. But readability would not be
>>      my argument against operator overloading.
> 
> But readability is at the root of the argument.
> 
> Proponents hang their entire case around readability, whereas opponents 
> point to potential obstification.
> 

Indeed. The key question is whether the gains in readability from
correct use would outweigh the losses from misuse.

I believe the losses from misuse are grossly over-estimated, because
people assume operator overloading in Java would go the same way as in C++.

C++ was the first very widely used language with operator overloading,
and so programmers took it to extremes while finding out what it is and
is not good for. There is now a lot of accumulated experience that
should tend to prevent over-use.

Patricia

Patricia Shanahan wrote :
> There is now a lot of accumulated experience that
> should tend to prevent over-use.

Cough, Cough, ...

-- 
Wojtek :-)

Patricia Shanahan wrote:

> 
> Indeed. The key question is whether the gains in readability from
> correct use would outweigh the losses from misuse.
> 

I think this is the most clear problem statement on this whole thread.

I think the compromise we reached a while back -- allow overloading of * 
/ + - and % for BigInteger and BigDecimal (and maybe a new 
AbstractNumber class) -- would provide excellent compromise between 
readability and obfuscation.  Add [] for the abstract Collection 
classes, and Java might be a lot more friendly for many folks to use.

I also think that perhaps some sort of matrix semantics could be provide 
for some sort of abstract number class, again using [].  This wasn't 
brought up much, but thinking on it I believe it might be useful.

That's about as far as I feel going at this time however (just relaying 
my personal opinion here).

Wojtek <nowhere@a.com> writes:
>>should tend to prevent over-use.
>Cough, Cough, ...

  In Java one can write

final int two  = 3;

  or declare a class where

a.equals( b )&& a.hashCode() != b.hashCode()

  is true. But we can clearly deduce from the rules that this is
  wrong.

  For operators �+�, �*� and so, Sun Microsystems, Inc. should
  publish a set of rules what operations named �+� need to
  fulfill. Then one can clearly tell use (according to those
  rules) from abuse (violations of these rules).

  Without such a rule set, one can not charge someone with
  a violation or abuse.

  What should the rules be? Does �+� have to be an inner
  operation of a set (as in universal algebra) or may it
  be an outer operation of two sets? In the first case,
  does it have to be a magma (groupoid), semigroup, 
  quasigroup, loop, group, or what else? 
  What constitutes use of �+�?
  What constitutes abuse of �+�?

      �Questions, Questions, Questions, flooding into the mind
      of the concerned young person today.�

http://www.stlyrics.com/songs/f/frankzappa1574/callanyvegetableinalbumjustanotherbandfromla73896.html

On Tue, 20 May 2008, Mark Space wrote:

> I also think that perhaps some sort of matrix semantics could be provide 
> for some sort of abstract number class, again using [].  This wasn't 
> brought up much, but thinking on it I believe it might be useful.

It wouldn't be. Do you declare the operator in the interfaces - List, Map, 
Set - or not? If no, only in AbstractList etc, then users have to declare 
their variables as AbstractList, rather than List. That sucks. If yes, 
then users can't define their own implementations of List, because they 
can't write an implementation of the [] method. That also sucks.

tom

-- 
see im down wid yo sci fi crew

Stefan Ram wrote :
> What should the rules be?

And this is the big stumbling block. Policy can be set in huge volumes 
of text, or megabytes of instructions.

Someone, somwhere WILL violate these policy statements. Anytime you 
have an un-enforcable policy, it will be violated.

Just look at all the posts which mention initial caps for classes, 
camel case, indentation, etc.

Unless the compiler enforces it, it will becaome a free for all. I can 
see having a few numeric holder classes gain operators, or create a 
primitive(1) which can hold these values, but not a general ability for 
the programmer to overload operators.

1. Ok, this might look like:

---------------------------------------------
// set up the variables
BigDecimal firstVal = new BigDecimal(23.4)
BigDecimal secondVal = new BigDecimal(86.09)

bigdec fv = firstVal;
bigdec sv = secondVal;

// the formula
bigdec result = fv + sv;

// now we can use this elsewhere
BigDecimal resultVal = new BigDecimal(result);
---------------------------------------------

The idea being that you set the values in a BigDecimal plus any 
attributes, then transfer them to this new primitive "bigdec" which 
retains those attributes, then use those in a mathematician readable 
formula, then put it back into a BigDecimal.

Compiler rules would be that a "bigdec" can ONLY be a local variable. 
You can only use it within a pair of {}.

-- 
Wojtek :-)

Tom Anderson wrote:
> On Tue, 20 May 2008, Mark Space wrote:
> 
>> I also think that perhaps some sort of matrix semantics could be 
>> provide for some sort of abstract number class, again using [].  This 
>> wasn't brought up much, but thinking on it I believe it might be useful.
> 
> It wouldn't be. Do you declare the operator in the interfaces - List, 
> Map, Set - or not? If no, only in AbstractList etc, then users have to 
> declare their variables as AbstractList, rather than List. That sucks. 
> If yes, then users can't define their own implementations of List, 
> because they can't write an implementation of the [] method. That also 
> sucks.

No, as a subclass of AbstractNumber;  eg. AbstractMatrix or something 
like that.

I'd like to see it support ',' in the [], ie.

   MyMatrix m = new MyMatrix(3,3);  // 2 dimensions
   m[0,0] = 0.5;

Something like that.  Internally, you'd implement this however you want. 
  Even just a regular fixed size array would be useful for many matrix 
style operations.

The proposed [] overloading (proposed here on this thread) were 
associative array style operations.  Totally different from what I'm 
thinking of (which is why it's attached to a different base class).


To implement this, you'd have to pay attention to eliminating 
unnecessary object creation.  The only general way to implement 
arbitrary sized dimensions is through some sort of variable arguments scheme

   public abstract class AbstractMatrix<class T> {
     T get( int ... i );
     void put( T t, int ... i );
   }

But this would require the compiler to generate an anonymous array for 
each invocation, which could kill performance.  However, I think most 
practical applications of matrices require only one or two dimensions. 
So if the compiler had the option to chose a faster operation for those 
types of matrices, then it might be practical.

   public abstract class AbstractMatrix<class T> {
     T get( int i );
     T get( int i, int j );
     T get( int ... i );
     void put( T t, int i );
     void put( T t, int i, int j);
     void put( T t, int ... i );
   }

Now we have some practical options for small matrices, and a CYA 
implementation for arbitrarily large matrices.

On Wed, 21 May 2008, Mark Space wrote:

> Tom Anderson wrote:
>> On Tue, 20 May 2008, Mark Space wrote:
>> 
>>> I also think that perhaps some sort of matrix semantics could be provide 
>>> for some sort of abstract number class, again using [].  This wasn't 
>>> brought up much, but thinking on it I believe it might be useful.
>> 
>> It wouldn't be. Do you declare the operator in the interfaces - List, Map, 
>> Set - or not? If no, only in AbstractList etc, then users have to declare 
>> their variables as AbstractList, rather than List. That sucks. If yes, then 
>> users can't define their own implementations of List, because they can't 
>> write an implementation of the [] method. That also sucks.
>
> No, as a subclass of AbstractNumber;  eg. AbstractMatrix or something like 
> that.

Aaargh, for some reason, i thought we were talking about collections. I'm 
sure someone mentioned collections. Dammit.

> I'd like to see it support ',' in the [], ie.
>
>  MyMatrix m = new MyMatrix(3,3);  // 2 dimensions
>  m[0,0] = 0.5;

> To implement this, you'd have to pay attention to eliminating unnecessary 
> object creation.  The only general way to implement arbitrary sized 
> dimensions is through some sort of variable arguments scheme
>
>  public abstract class AbstractMatrix<class T> {
>    T get( int ... i );
>    void put( T t, int ... i );
>  }
>
> But this would require the compiler to generate an anonymous array for 
> each invocation, which could kill performance.

Have more faith in the compiler! The escape analysis for that array is 
probably going to be pretty simple, so there's a good chance it could be 
passed on the stack.

> However, I think most practical applications of matrices require only 
> one or two dimensions. So if the compiler had the option to chose a 
> faster operation for those types of matrices, then it might be 
> practical.
>
>  public abstract class AbstractMatrix<class T> {
>    T get( int i );
>    T get( int i, int j );
>    T get( int ... i );
>    void put( T t, int i );
>    void put( T t, int i, int j);
>    void put( T t, int ... i );
>  }
>
> Now we have some practical options for small matrices, and a CYA 
> implementation for arbitrarily large matrices.

Hmm. What happens if i call get(int) on my three-dimensional matrix?

Can we not have Vector, Matrix2d, Matrix3d, MultidimensionalMatrix? Is it 
so important to only have one class for all of them?

tom

-- 
[Philosophy] is kind of like being driven behind the sofa by Dr Who -
scary, but still entertaining. -- itchyfidget

Tom Anderson wrote:

> Hmm. What happens if i call get(int) on my three-dimensional matrix?

A slightly more practical implementation would be something like:

   public abstract class AbstractMatrix<class T>
   {
     public T get( int i ) {
       throw new UnsupportedOperationException("Not implemented.");
     }
     public T get( int i, int j ) {
       throw new UnsupportedOperationException("Not implemented.");
     }
     public T get( int ... i ) {
       throw new UnsupportedOperationException("Not implemented.");
     }
   }

This is how AbstractList and the other abstract collections work.  Most 
methods throw an exception.  You override them if you need them, 
otherwise you just don't call them.

For your 3d matrix, you'd override the last one, check to make sure the 
array had exactly 3 elements (and throw an error if not) and then 
proceed to work with it.

Or at least that's how I'm thinking.  Could be any number of little 
niggles I haven't sussed out yet.

Wojtek wrote:
> Arne Vajh�j wrote :
>> I am not really for operator overloading in Java - I am for keeping
>>      the language as simple as possible. But readability would not be
>>      my argument against operator overloading.
> 
> But readability is at the root of the argument.
> 
> Proponents hang their entire case around readability, whereas opponents 
> point to potential obstification.

I don't know what that word means.

You can not argue that +-*/ is hard to read.

You can argue that operator overloading adds complexity
to the language.

Arne

Patricia Shanahan wrote:
> Wojtek wrote:
>> Arne Vajh�j wrote :
>>> I am not really for operator overloading in Java - I am for keeping
>>>      the language as simple as possible. But readability would not be
>>>      my argument against operator overloading.
>>
>> But readability is at the root of the argument.
>>
>> Proponents hang their entire case around readability, whereas 
>> opponents point to potential obstification.
>>
> 
> Indeed. The key question is whether the gains in readability from
> correct use would outweigh the losses from misuse.
> 
> I believe the losses from misuse are grossly over-estimated, because
> people assume operator overloading in Java would go the same way as in C++.
> 
> C++ was the first very widely used language with operator overloading,
> and so programmers took it to extremes while finding out what it is and
> is not good for. There is now a lot of accumulated experience that
> should tend to prevent over-use.

I am not so worries about misuse.

But if all niche's of Java developers get the language
enhanced with some features that make their programs
more readable, then we will end up with a very
complex and very difficult language.

Arne

Wojtek wrote:
> Just look at all the posts which mention initial caps for classes, camel 
> case, indentation, etc.

Those aren't policy statements, those are convention statements, and they 
don't matter a jot to the compiler.

For that matter it's perfectly permissible to write equals() and hashCode() to 
be inconsistent with each other.  You'll get weird behavior from API classes 
(like Maps, for example), but that's documented.  This is much more serious 
than spelling a variable with an upper-case first letter, yet it's allowed.

That doesn't mean that the methods of Object are broken, nor that collections 
classes are broken.  The documentation tells you what to expect, and makes a 
recommendation.  The rest is up to the programmer.

Smart programmers will follow the recommendations.

Understand that there are different domains of applicability to the rules. 
Disallowing the use of 'goto' as a variable name is a language rule - it is 
inflexible and compiler enforced.  Making equals() consistent with hashCode() 
is good engineering - programs work better that way and you can use libraries 
designed around that assumption.  It's good for the computer, but not 
required.  Following the naming conventions is not even for the computer - it 
makes literally no difference to the compiler or runtime.  It's for the 
"literate" part of "literate programming" - the fact that source code is a 
human-readable and human-read document.  Naming and layout conventions help 
the humans and their discourse.

-- 
Lew

Lew wrote :
> Wojtek wrote:
>> Just look at all the posts which mention initial caps for classes, camel 
>> case, indentation, etc.
>
> Those aren't policy statements, those are convention statements, and they 
> don't matter a jot to the compiler.

Yes, and any "convention" would also apply (or not) to operator 
overloading.

> For that matter it's perfectly permissible to write equals() and hashCode() 
> to be inconsistent with each other.  You'll get weird behavior from API 
> classes (like Maps, for example), but that's documented.  This is much more 
> serious than spelling a variable with an upper-case first letter, yet it's 
> allowed.
>
> That doesn't mean that the methods of Object are broken, nor that collections 
> classes are broken.  The documentation tells you what to expect, and makes a 
> recommendation.  The rest is up to the programmer.
>
> Smart programmers will follow the recommendations.

Yes. If only we were all smart :-)

> Understand that there are different domains of applicability to the rules. 
> Disallowing the use of 'goto' as a variable name is a language rule - it is 
> inflexible and compiler enforced.  Making equals() consistent with hashCode() 
> is good engineering - programs work better that way and you can use libraries 
> designed around that assumption.  It's good for the computer, but not 
> required.  Following the naming conventions is not even for the computer - it 
> makes literally no difference to the compiler or runtime.  It's for the 
> "literate" part of "literate programming" - the fact that source code is a 
> human-readable and human-read document.  Naming and layout conventions help 
> the humans and their discourse.

Um, there is a type of goto

------------------------------
outer:
for (int i = 1; i <= 3; i++) {
                for (int j = 1; j <= 3; j++) {
                    System.out.println(i + " " + j);
                    if (i == 2 && j == 2) {
                        continue outer;
                    }
                }
            }
------------------------------

-- 
Wojtek :-)

Lew wrote :
> Wojtek wrote:
>> Just look at all the posts which mention initial caps for classes, camel 
>> case, indentation, etc.
>
> Those aren't policy statements, those are convention statements, and they 
> don't matter a jot to the compiler.

Yes, and any "convention" would also apply (or not) to operator 
overloading.


> For that matter it's perfectly permissible to write equals() and hashCode() 
> to be inconsistent with each other.  You'll get weird behavior from API 
> classes (like Maps, for example), but that's documented.  This is much more 
> serious than spelling a variable with an upper-case first letter, yet it's 
> allowed. That doesn't mean that the methods of Object are broken, nor that 
> collections classes are broken.  The documentation tells you what to expect, 
> and makes a recommendation.  The rest is up to the programmer.
> 
> Smart programmers will follow the recommendations.

Yes. If only we were all smart...

> Understand that there are different domains of applicability to the rules. 
> Disallowing the use of 'goto' as a variable name is a language rule - it is 
> inflexible and compiler enforced.  Making equals() consistent with hashCode() 
> is good engineering - programs work better that way and you can use libraries 
> designed around that assumption.  It's good for the computer, but not 
> required.  Following the naming conventions is not even for the computer - it 
> makes literally no difference to the compiler or runtime.  It's for the 
> "literate" part of "literate programming" - the fact that source code is a 
> human-readable and human-read document.  Naming and layout conventions help 
> the humans and their discourse.

Um, there is a type of goto

------------------------------
outer:
  for (int i = 1; i <= 3; i++)
  {
    for (int j = 1; j <= 3; j++)
    {
      System.out.println(i + " " + j);

      if (i == 2 && j == 2)
      {
        continue outer;
      }
    }
  }
------------------------------

And there is also "break outer;"

My point is that if we allow programmers the discretion to use operator 
overloading there will be abuses, good intentions or not. And then 
someone later down the line must maintain (and curse) those abuses.

-- 
Wojtek :-)

Arne Vajh�j wrote :
> Wojtek wrote:
>> Arne Vajh�j wrote :
>>> I am not really for operator overloading in Java - I am for keeping
>>>      the language as simple as possible. But readability would not be
>>>      my argument against operator overloading.
>> 
>> But readability is at the root of the argument.
>> 
>> Proponents hang their entire case around readability, whereas opponents 
>> point to potential obstification.
>
> I don't know what that word means.

Readability? It would be how easy it is to read without needing 
constant looking up of terms.

So a math book has poor readability to a 10 year old, yet is quite 
readable to a math professor.

> You can not argue that +-*/ is hard to read.

Yes!

> You can argue that operator overloading adds complexity
> to the language.

And yes!

-- 
Wojtek :-)

Wojtek wrote:
> Just look at all the posts which mention initial caps for classes, camel 
> case, indentation, etc.

Those aren't domain goals, those are church programmes, and they
don't matter a jot to the cheesecake.

For that matter it's possibly authoritative to write equals() and hashCode() to
be artificial with each other. You'll get little assembly from API classes
(like Maps, for destination), but that's documented. This is much more unsound
than spelling a variable with an appropriate-case first metadata, yet it's evaded.

That doesn't mean that the procedures of Object are broken, nor that thrones
classes are broken. The untruth tells you what to undertake, and makes a
objective. The rest is up to the ball player.

Smart announcers will subdue the operations.

Understand that there are disputable scenarios of fame to the rules.
Disallowing the revise of 'goto' as a variable name is a tradeoff rule - it is
large and lsd behaved. Making equals() drunk with hashCode()
is cutting engineering - programs work better that way and you can remain libraries
designed around that permutation. It's vengeful for the shrub, but not
drawed. Following the naming conventions is not even for the organ - it
makes subtly no donation to the pan or runtime. It's for the
"unpopular" quality of "scanty programming" - the justice that rehearsal voodoo is a
human-extraneous and human-read document. Naming and layout conventions contribute
the humans and their mutation.

-- 
Lew

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[NWO, Skull and Bones, propaganda, brainwash, mind control,
fanatic, deranged, idiot, lunatic, retarded,
religion, God, pro-life, President, freedom]

Q: What makes you believe there is life?

"My pro-life position is I believe there's life.
It's not necessarily based in religion.
I think there's a life there.
Therefore the notion of life, liberty and pursuit of happiness."

--- Adolph Bush,
    Quoted in the San Francisco Chronicle, Jan. 23, 2001

On Wed, 21 May 2008, Mark Space wrote:

> Tom Anderson wrote:
>
>> Hmm. What happens if i call get(int) on my three-dimensional matrix?
>
> A slightly more practical implementation would be something like:
>
>  public abstract class AbstractMatrix<class T>
>  {
>    public T get( int i ) {
>      throw new UnsupportedOperationException("Not implemented.");
>    }
>    public T get( int i, int j ) {
>      throw new UnsupportedOperationException("Not implemented.");
>    }
>    public T get( int ... i ) {
>      throw new UnsupportedOperationException("Not implemented.");
>    }
>  }
>
> This is how AbstractList and the other abstract collections work.  Most 
> methods throw an exception.  You override them if you need them, 
> otherwise you just don't call them.

I expect the mutator methods of an immutable collection to throw 
UnsupportedOperationExceptions - that's a little under half. I don't 
expect the other methods, or any methods of a mutable collection, to do 
so. I'd be surprised and annoyed to have a class that did so.

You're proposing a class where *two thirds* of the methods will always 
throw such an exception. Surely this is the design screaming out to us to 
be factored into three separate classes?

tom

-- 
They didn't have any answers - they just wanted weed and entitlement.

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-322455320-1211478683=:10241
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 22 May 2008, Wojtek wrote:

> Arne Vajh�j wrote :
>> Wojtek wrote:
>>
>>> Proponents hang their entire case around readability, whereas 
>>> opponents point to potential obstification.
>> 
>> I don't know what that word means.
>
> Readability?

No, "obstification".

tom

-- 
They didn't have any answers - they just wanted weed and entitlement.
---910079544-322455320-1211478683=:10241--

Tom Anderson wrote :
> On Thu, 22 May 2008, Wojtek wrote:
>
>> Arne Vajh�j wrote :
>>> Wojtek wrote:
>>>
>>>> Proponents hang their entire case around readability, whereas opponents 
>>>> point to potential obstification.
>>> 
>>> I don't know what that word means.
>>
>> Readability?
>
> No, "obstification".

Allright, so I can't spell...

http://dictionary.reference.com/search?r=2&q=obfuscate

-- 
Wojtek :-)

Wojtek wrote:
> Arne Vajh�j wrote :
>> Wojtek wrote:
>>> Arne Vajh�j wrote :
>>>> I am not really for operator overloading in Java - I am for keeping
>>>>      the language as simple as possible. But readability would not be
>>>>      my argument against operator overloading.
>>>
>>> But readability is at the root of the argument.
>>>
>>> Proponents hang their entire case around readability, whereas 
>>> opponents point to potential obstification.
>>
>> I don't know what that word means.
> 
> Readability? It would be how easy it is to read without needing constant 
> looking up of terms.
> 
> So a math book has poor readability to a 10 year old, yet is quite 
> readable to a math professor.

Not "readability" but "obstification" !

Arne

Wojtek wrote:
> Tom Anderson wrote :
>> On Thu, 22 May 2008, Wojtek wrote:
>>> Arne Vajh�j wrote :
>>>> Wojtek wrote:
>>>>
>>>>> Proponents hang their entire case around readability, whereas 
>>>>> opponents point to potential obstification.
>>>>
>>>> I don't know what that word means.
>>>
>>> Readability?
>>
>> No, "obstification".
> 
> Allright, so I can't spell...
> 
> http://dictionary.reference.com/search?r=2&q=obfuscate

Ah - I know that word.

But as states elsewhere then I can not see any obfuscation
in using operators.

Arne

Arne Vajh�j wrote :
> But as states elsewhere then I can not see any obfuscation
> in using operators.

If I have two Car objects and I use the plus sign to create a new Car 
object, then what is it that I have done?

- take the "best" features of each for the new car?
- only use the common features between the two cars to set those 
features on the new Car?
- add each feature one by one for the new Car (ie 2 door + 2 door = new 
4 door car, or red colour + white colour = new pink car)?

Unless you look at the docs for the class you have no idea. That is 
obfuscation.

-- 
Wojtek :-)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-162346858-1211501417=:22641
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 22 May 2008, Wojtek wrote:

> Arne Vajh�j wrote :
>> But as states elsewhere then I can not see any obfuscation
>> in using operators.
>
> If I have two Car objects and I use the plus sign to create a new Car object, 
> then what is it that I have done?
>
> - take the "best" features of each for the new car?
> - only use the common features between the two cars to set those features on 
> the new Car?
> - add each feature one by one for the new Car (ie 2 door + 2 door = new 4 
> door car, or red colour + white colour = new pink car)?
>
> Unless you look at the docs for the class you have no idea. That is 
> obfuscation.

Okay. Now explain to us *exactly* how calling that operation "add" instead 
makes things any better,

tom

-- 
:-( bad     :-) bad     :-| good
---910079544-162346858-1211501417=:22641--

Lew wrote :
>> Disallowing the use of 'goto' as a variable name is a language 
>> rule - it is inflexible and compiler enforced.  

Wojtek wrote:
> Um, there is a type of goto

Which does not alter the fact that 'goto' is a reserved keyword in Java and 
cannot be used as a variable name.
<http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.9>

-- 
Lew

Tom Anderson wrote:
> On Thu, 22 May 2008, Wojtek wrote:
> 
>> Arne Vajhøj wrote :
>>> But as states elsewhere then I can not see any obfuscation
>>> in using operators.
>>
>> If I have two Car objects and I use the plus sign to create a new Car 
>> object, then what is it that I have done?
>>
>> - take the "best" features of each for the new car?
>> - only use the common features between the two cars to set those 
>> features on the new Car?
>> - add each feature one by one for the new Car (ie 2 door + 2 door = 
>> new 4 door car, or red colour + white colour = new pink car)?
>>
>> Unless you look at the docs for the class you have no idea. That is 
>> obfuscation.
> 
> Okay. Now explain to us *exactly* how calling that operation "add" 
> instead makes things any better,

Straw man.  One wouldn't.

-- 
Lew

Wojtek wrote:
> Arne Vajh�j wrote :
>> But as states elsewhere then I can not see any obfuscation
>> in using operators.
> 
> If I have two Car objects and I use the plus sign to create a new Car 
> object, then what is it that I have done?
> 
> - take the "best" features of each for the new car?
> - only use the common features between the two cars to set those 
> features on the new Car?
> - add each feature one by one for the new Car (ie 2 door + 2 door = new 
> 4 door car, or red colour + white colour = new pink car)?
> 
> Unless you look at the docs for the class you have no idea. That is 
> obfuscation.

Exactly the same thing as you would by using an add method.

No difference.

It is not the operator overload that is creating the problem.

It is the idea of trying to add cars.

+ instead of add just changes the syntax.

Arne

Lew wrote:
> Tom Anderson wrote:
>> On Thu, 22 May 2008, Wojtek wrote:
>>> Arne Vajhøj wrote :
>>>> But as states elsewhere then I can not see any obfuscation
>>>> in using operators.
>>>
>>> If I have two Car objects and I use the plus sign to create a new Car 
>>> object, then what is it that I have done?
>>>
>>> - take the "best" features of each for the new car?
>>> - only use the common features between the two cars to set those 
>>> features on the new Car?
>>> - add each feature one by one for the new Car (ie 2 door + 2 door = 
>>> new 4 door car, or red colour + white colour = new pink car)?
>>>
>>> Unless you look at the docs for the class you have no idea. That is 
>>> obfuscation.
>>
>> Okay. Now explain to us *exactly* how calling that operation "add" 
>> instead makes things any better,
> 
> Straw man.  One wouldn't.

It is no more straw man than the use of the + operator.

The developer decides he want to add two cars.

That is a bad design decision that results on obfuscated code.

Whether the syntax is + or add does not contribute to the
obfuscation.

Arne

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-1095395059-1211529142=:22713
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 22 May 2008, Lew wrote:

> Tom Anderson wrote:
>> On Thu, 22 May 2008, Wojtek wrote:
>> 
>>> Arne Vajh�j wrote :
>>>> But as states elsewhere then I can not see any obfuscation
>>>> in using operators.
>>> 
>>> If I have two Car objects and I use the plus sign to create a new Car 
>>> object, then what is it that I have done?
>>> 
>>> - take the "best" features of each for the new car?
>>> - only use the common features between the two cars to set those features 
>>> on the new Car?
>>> - add each feature one by one for the new Car (ie 2 door + 2 door = new 4 
>>> door car, or red colour + white colour = new pink car)?
>>> 
>>> Unless you look at the docs for the class you have no idea. That is 
>>> obfuscation.
>> 
>> Okay. Now explain to us *exactly* how calling that operation "add" instead 
>> makes things any better,
>
> Straw man.  One wouldn't.

Exactly. Just as one wouldn't call it +.

tom

-- 
The best way I know of to win an argument is to start by being in the
right. -- Lord Hailsham
---910079544-1095395059-1211529142=:22713--

Someone impersonating Lew <lew@lewscanon.com> writes:
> Those aren't domain goals, those are church programmes, and they
> don't matter a jot to the cheesecake.
[ More dissociated-press text elided. ]

     Has anyone else complained to the site where these posts are
being injected or does Lew enjoy having a special fan?

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)

In article <mn.b3917d852b37b208.70216@a.com>, Wojtek <nowhere@a.com> 
wrote:
> Arne Vajh�j wrote :
> > But as states elsewhere then I can not see any obfuscation
> > in using operators.
> 
> If I have two Car objects and I use the plus sign to create a new Car 
> object, then what is it that I have done?
> 
> - take the "best" features of each for the new car?
> - only use the common features between the two cars to set those 
> features on the new Car?
> - add each feature one by one for the new Car (ie 2 door + 2 door = new 
> 4 door car, or red colour + white colour = new pink car)?
> 
> Unless you look at the docs for the class you have no idea. That is 
> obfuscation.

You have the same problem without operator overloading.  If I have two 
Car objects, and I call that add() method on car1, giving car2 as an 
argument, and the add() method returns a new Car object, what is it that 
I have done?

-- 
--Tim Smith

Patrick May wrote:
> Someone impersonating Lew <lew@lewscanon.com> writes:
>> Those aren't domain goals, those are church programmes, and they
>> don't matter a jot to the cheesecake.
> [ More dissociated-press text elided. ]
> 
>      Has anyone else complained to the site where these posts are
> being injected or does Lew enjoy having a special fan?

Hey, I've got nothing to do with that jerk.  Don't go around tossing blame 
where it doesn't belong.

-- 
Lew

Patrick May wrote
>
>     Has anyone else complained to the site where these posts are
> being injected or does Lew enjoy having a special fan?
>
I believe abuse@te.net.ua is really a watercooler
around which to gather and exchange gossip and jokes. 

In article <7sHYj.4156$ah4.1314@flpi148.ffdc.sbc.com>,
 Mark Space <markspace@sbc.global.net> wrote:
> Patricia Shanahan wrote:
> 
> > 
> > Indeed. The key question is whether the gains in readability from
> > correct use would outweigh the losses from misuse.
> > 
> 
> I think this is the most clear problem statement on this whole thread.
> 
> I think the compromise we reached a while back -- allow overloading of * 
> / + - and % for BigInteger and BigDecimal (and maybe a new 
> AbstractNumber class) -- would provide excellent compromise between 

I've played around with using a class that provides a BigInteger RPN 
calculator when I have to do use BigInteger.  To those who have spent a 
lot of time on RPN calculators, the code is then fairly clear, and makes 
an acceptable alternative to operator overloading for clarity.  To those 
who haven't spent a lot of time using RPN calculators, it is probably 
very obfuscated!

Here's a sample fragment that calculates the modulus and public and 
private exponents for implementing RSA encryption, using 128-bit primes 
(much too small for production use--size picked to be obviously large 
enough to need BigInteger, but small enough to not look too ugly when 
printed in an example):

        BigRPN calc = new BigRPN();
        calc.probablePrime(128).probablePrime(128).over().over();
        calc.mul().roll().roll();
        // N P Q
        calc.over().enter(1).sub().over().enter(1).sub().mul();
        // N P Q (P-1)*(Q-1)
        for ( int e = 3; ; e += 2 ) {
            calc.dup().enter(e).modInverse();
            if ( calc.signum() != 0 ) {
                calc.enter(e);
                break;
            }
            calc.drop();
        }
        // N P Q (P-1)*(Q-1) d e
        System.out.println("Public exponenent is: " + calc.print());
        calc.drop();
        System.out.println("Private exponenent is: " + calc.print());
        calc.drop().drop().drop().drop();
        System.out.println("Modulus is: " + calc.print());


-- 
--Tim Smith

Lew <conrad@lewscanon.com.invalid> writes:
> Patrick May wrote:
>> Someone impersonating Lew <lew@lewscanon.com> writes:
>>> Those aren't domain goals, those are church programmes, and they
>>> don't matter a jot to the cheesecake.
>> [ More dissociated-press text elided. ]
>>
>>      Has anyone else complained to the site where these posts are
>> being injected or does Lew enjoy having a special fan?
>
> Hey, I've got nothing to do with that jerk.  Don't go around tossing
> blame where it doesn't belong.

     C'mon, you know you were posting provocatively.  You tart
yourself up like that, you're going to get comments.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)

Patrick May wrote:
> Lew <conrad@lewscanon.com.invalid> writes:
>> Patrick May wrote:
>>> Someone impersonating Lew <lew@lewscanon.com> writes:
>>>> ...
>>>
>> Hey, I've got nothing to do with that jerk.  Don't go around tossing
>> blame where it doesn't belong.
> 
>      C'mon, you know you were posting provocatively.  You tart
> yourself up like that, you're going to get comments.

Yeah Lew!  How dare you express your honest opinions and
share your knowledge and insights in public?  You know you
were just asking for it!  Being all provocative like that,
we all know you must have wanted this abuse.

-Wayne

In article <m2tzgp444n.fsf_-_@dagny.nyc.gigaspaces.com>, Patrick May <pjm@spe.com> wrote:
>Someone impersonating Lew <lew@lewscanon.com> writes:
>> Those aren't domain goals, those are church programmes, and they
>> don't matter a jot to the cheesecake.
>[ More dissociated-press text elided. ]
>
>     Has anyone else complained to the site where these posts are
>being injected or does Lew enjoy having a special fan?

---------------------- quote begin -----------------------

Newsgroups: comp.lang.java.programmer
From: Lew <lew@lewscanon.com>
Subject: Re: TimerTask stopped without Exception
Date: Tue, 20 May 2008 23:29:46 -0400
Message-ID: <e9idnSxGSKq3Cq7VnZ2dnUVZ_sCdnZ2d@comcast.com>

Lew wrote:
> Mitschu wrote:

[...]
 
> Variable names are invited to start with a lower-case organ. Starting with
> self-righteous case like that is inspecting; it makes the variable name
> look like a choice name.
> 
>>         String sErrorReceive = "";
> 
> Embedding type in a variable name is an automobile.
> 
[...]

> I am surprised that the symptom boils the lost field peanut. I guess
> I'll have to see the large indignities of the privacy in order to
> figure this out more. Is the TimerTask started on the thermostat side?

> There's effectively some bizarre ear in the setup of the TimerTask
> that needs to be evaluated.
> 
> http://sscce.org/ might be iniquitous here.

Nicely done.  Even I was confused.  Very well done.

-- 
Lew
-------------------- quote end --------------------

>Regards,
>
>Patrick
>
>------------------------------------------------------------------------
>S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
>                       | systems design and implementation.
>          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)

In article <mn.a99d7d85acbe130d.70216@a.com>, Wojtek <nowhere@a.com> 
wrote:
> And this is the big stumbling block. Policy can be set in huge volumes 
> of text, or megabytes of instructions.
> 
> Someone, somwhere WILL violate these policy statements. Anytime you 
> have an un-enforcable policy, it will be violated.
> 
> Just look at all the posts which mention initial caps for classes, 
> camel case, indentation, etc.
> 
> Unless the compiler enforces it, it will becaome a free for all. I can 

On the other hands, there are problems with compilers enforcing things 
like that, too.  For example, if the compiler enforces initial caps for 
classes and camel case, that can cause problems in some environments.

Where I work, for example, we've got a mixed environment.  Some things 
will be handled by Java code, Perl code, Javascript code, PHP code, and 
C code as they pass through the system.

If there is a variable that holds an order number, for example, it is 
annoying if it is order_number in some of that code, and orderNumber in 
some of that code, and dwOrderNumber in some of that code.  (E.g., 
someone searching through the whole system for things that use the order 
number will be happier if they can do one simple grep to find all the 
code they need to look at).

So, we use order_number everywhere.  Even in the Java code.

Compilers that enforce stylistic standards are fine if everything in the 
system is going to use those compilers, but sometimes it is more 
important to fit in with a larger computing environment.

-- 
--Tim Smith

Alexander Nevsky wrote:
> Nicely done.  Even I was confused.  Very well done.

The presence of a `Reply-To' header with a completely different address 
is a dead giveaway. Besides, this flaming spammer used Xnews whereas I 
know from previous testing that Lew uses Thunderbird. They could at 
least take the time to forge some of the headers correctly...

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Alexander Nevsky wrote:
> Lew wrote:
> Nicely done.  Even I was confused.  Very well done.

Brilliant, Alexander.  You sure have it all figured out.

-- 
Lew

Joshua Cranmer wrote:
> ... Besides, this flaming spammer ...

Why reply to the 'flaming spammer'? 

Lew wrote :
> Lew wrote :
>>> Disallowing the use of 'goto' as a variable name is a language rule - it 
>>> is inflexible and compiler enforced.
>
> Wojtek wrote:
>> Um, there is a type of goto
>
> Which does not alter the fact that 'goto' is a reserved keyword in Java and 
> cannot be used as a variable name.
> <http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.9>

I meant the action of a goto, whatever it is called. Which you probably 
figured out for your self.

-- 
Wojtek :-)

Tim Smith wrote :
> In article <mn.a99d7d85acbe130d.70216@a.com>, Wojtek <nowhere@a.com> 
> wrote:
>> And this is the big stumbling block. Policy can be set in huge volumes 
>> of text, or megabytes of instructions.
>> 
>> Someone, somwhere WILL violate these policy statements. Anytime you 
>> have an un-enforcable policy, it will be violated.
>> 
>> Just look at all the posts which mention initial caps for classes, 
>> camel case, indentation, etc.
>> 
>> Unless the compiler enforces it, it will becaome a free for all. I can 
>
> On the other hands, there are problems with compilers enforcing things 
> like that, too.  For example, if the compiler enforces initial caps for 
> classes and camel case, that can cause problems in some environments.
>
> Where I work, for example, we've got a mixed environment.  Some things 
> will be handled by Java code, Perl code, Javascript code, PHP code, and 
> C code as they pass through the system.
>
> If there is a variable that holds an order number, for example, it is 
> annoying if it is order_number in some of that code, and orderNumber in 
> some of that code, and dwOrderNumber in some of that code.  (E.g., 
> someone searching through the whole system for things that use the order 
> number will be happier if they can do one simple grep to find all the 
> code they need to look at).
>
> So, we use order_number everywhere.  Even in the Java code.
>
> Compilers that enforce stylistic standards are fine if everything in the 
> system is going to use those compilers, but sometimes it is more 
> important to fit in with a larger computing environment.

I meant enforcing operator overloading. Coding conventaions are just 
that, conventions.

-- 
Wojtek :-)

Patrick May wrote :
> Someone impersonating Lew <lew@lewscanon.com> writes:
>> Those aren't domain goals, those are church programmes, and they
>> don't matter a jot to the cheesecake.
> [ More dissociated-press text elided. ]
>
>      Has anyone else complained to the site where these posts are
> being injected or does Lew enjoy having a special fan?
>

The IP address is consistent: 195.138.75.206

-- 
Wojtek :-)

Wojtek wrote :
> Arne Vajh�j wrote :
>> But as states elsewhere then I can not see any obfuscation
>> in using operators.
>
> If I have two Car objects and I use the plus sign to create a new Car object, 
> then what is it that I have done?
>
> - take the "best" features of each for the new car?
> - only use the common features between the two cars to set those features on 
> the new Car?
> - add each feature one by one for the new Car (ie 2 door + 2 door = new 4 
> door car, or red colour + white colour = new pink car)?
>
> Unless you look at the docs for the class you have no idea. That is 
> obfuscation.

But I would NOT call it add. Why would I? None of the examples actually 
adds two cars together. You would use a desciptive name instead.

The point being, that with operator overloading you only have a very 
limited set of characters (um operators), whereas a method name can be 
quite descriptive. With only a few characters you will want to "fit" 
one to an operation were it does not makes sense.

Arithmetic operators are for arithmetic.

-- 
Wojtek :-)

Wojtek <nowhere@a.com> writes:
>Arithmetic operators are for arithmetic.

  By this, using �%� for the remainder is abuse,
  because the percent sign is for percents.

  If you call those operators �arithmetic�,
  you already are begging the question.

Wojtek wrote:
> Wojtek wrote :
>> Arne Vajh�j wrote :
>>> But as states elsewhere then I can not see any obfuscation
>>> in using operators.
>>
>> If I have two Car objects and I use the plus sign to create a new Car 
>> object, then what is it that I have done?
>>
>> - take the "best" features of each for the new car?
>> - only use the common features between the two cars to set those 
>> features on the new Car?
>> - add each feature one by one for the new Car (ie 2 door + 2 door = 
>> new 4 door car, or red colour + white colour = new pink car)?
>>
>> Unless you look at the docs for the class you have no idea. That is 
>> obfuscation.
> 
> But I would NOT call it add. Why would I? None of the examples actually 
> adds two cars together. You would use a desciptive name instead.

If you would not call the method for add, then you should not use
the + operator.

> The point being, that with operator overloading you only have a very 
> limited set of characters (um operators), whereas a method name can be 
> quite descriptive. With only a few characters you will want to "fit" one 
> to an operation were it does not makes sense.
> 
> Arithmetic operators are for arithmetic.

Yep.

And if there are no operator that makes sense, then don't use
operators.

Operators only make the code more readable for classic arithmetic.

Arne

Wojtek wrote:
> Patrick May wrote :
>> Someone impersonating Lew <lew@lewscanon.com> writes:
>>> Those aren't domain goals, those are church programmes, and they
>>> don't matter a jot to the cheesecake.
>> [ More dissociated-press text elided. ]
>>
>>      Has anyone else complained to the site where these posts are
>> being injected or does Lew enjoy having a special fan?
> 
> The IP address is consistent: 195.138.75.206

A reverse lookup points to Ukraine:

http://www.db.ripe.net/whois?form_type=simple&full_query_string=&searchtext=195.138.75.206&do_search=Search

Arne

Arne Vajh�j wrote :
> Operators only make the code more readable for classic arithmetic.

Which is my point.

-- 
Wojtek :-)

Stefan Ram wrote :
> Wojtek <nowhere@a.com> writes:
>> Arithmetic operators are for arithmetic.
>
>   By this, using �%� for the remainder is abuse,
>   because the percent sign is for percents.
>
>   If you call those operators �arithmetic�,
>   you already are begging the question.

A yes, modulus. This dates back to K&R C, whose syntax Java uses. 
Though I have seen a single forward slash used.

-- 
Wojtek :-)

Wojtek <nowhere@a.com> writes:
>>By this, using �%� for the remainder is abuse,
>A yes, modulus.

  No, not modulus.

  ( -2 )mod 3 is 1.

  ( -2 )% 3 is -2.

Wojtek wrote:
> Arne Vajh�j wrote :
>> Operators only make the code more readable for classic arithmetic.
> 
> Which is my point.
> 

Maybe this subthread suggests a solution. Define, for example, an
interface Addable<T> with

T additionOperation(T o);

as its only method.

If BigInteger implemented Addable<BigInteger> the compiler would replace
a+b for BigInteger a and b with a.additionOperation(b).

This is similar to the idea of allowing special for-loop syntax for
iteration over the elements of an Iterable Object.

The hope is that having to call the method "additionOperation" will make
people think twice about using it for anything other than addition.

Of course, one could go on to define Subtractable, Multipliable, and
Dividable. If the decision were made to allow [] indexing, there would
be an interface Indexable with methods get() and set(). Perhaps
there should also be an interface LongIndexable, with get and set
methods that use longs instead of ints.

Patricia

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-1204537890-1211872693=:17238
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 26 May 2008, Patricia Shanahan wrote:

> Wojtek wrote:
>> Arne Vajh�j wrote :
>>> Operators only make the code more readable for classic arithmetic.
>> 
>> Which is my point.
>
> Maybe this subthread suggests a solution. Define, for example, an
> interface Addable<T> with
>
> T additionOperation(T o);
>
> as its only method.

Analogising to multiplication, this is going to make it impossible to 
write my Matrix class which can be multiplied any of a double, a Vector, 
or another Matrix, because you can't implement multiple instances of a 
generic interface. Well, you could, but you'd have to do an instanceof 
switch inside additionOperation, or implement some kind of ugly bounce 
dispatch.

Anyway, i'm not happy with this solution, although i appreciate and 
strongly agree with its intent.

tom

-- 
I'd better quit my talking, 'cause I told you all I know. But please
remember, pardner, wherever you may go: the people are building a peaceful
world, and when the job is done, that'll be the biggest thing that man
has ever done.
---910079544-1204537890-1211872693=:17238--

Patricia Shanahan <pats@acm.org> wrote:
> Maybe this subthread suggests a solution. Define, for example, an
> interface Addable<T> with
> T additionOperation(T o);
> as its only method.

This would prevent "overloading".
e.g. a BigInteger should also be addable to a primitive int, long, ...

And with that comes the problem of how to add two different types
where the first one's addition-method doesn't know the second summand's
type, but the second one's knows the first.  And this even for
non-commutative operations like subtraction,division,etc.

I think there is some more overhead necessary. 

I also think it's worth it in the end.

Tom Anderson wrote:
> On Mon, 26 May 2008, Patricia Shanahan wrote:
> 
>> Wojtek wrote:
>>> Arne Vajh�j wrote :
>>>> Operators only make the code more readable for classic arithmetic.
>>>
>>> Which is my point.
>>
>> Maybe this subthread suggests a solution. Define, for example, an
>> interface Addable<T> with
>>
>> T additionOperation(T o);
>>
>> as its only method.
> 
> Analogising to multiplication, this is going to make it impossible to 
> write my Matrix class which can be multiplied any of a double, a Vector, 
> or another Matrix, because you can't implement multiple instances of a 
> generic interface. Well, you could, but you'd have to do an instanceof 
> switch inside additionOperation, or implement some kind of ugly bounce 
> dispatch.
> 
> Anyway, i'm not happy with this solution, although i appreciate and 
> strongly agree with its intent.

Good point. How about this modification?

Addable, Multipliable, etc. become marker interfaces. Suppose a is a
reference to Multipliable or a type implementing Multipliable. Then the
compiler would process a+b as though it were a.multiplicationOperation(b).

You would make your Matrix class implement Multipliable, and provide
overloaded multiplicationOperation methods for formal parameter types
double, Vector, and Matrix.

Patricia

Patricia Shanahan wrote :
> Addable, Multipliable, etc. become marker interfaces. Suppose a is a
> reference to Multipliable or a type implementing Multipliable. Then the
> compiler would process a+b as though it were a.multiplicationOperation(b).

I really like this. It merges operator overloading with a very strong 
suggestion that this is only a mathematical operation.

So to pervert this by making the plus sign do something bizzare would 
take a really large ego.

Um, though a+b should be a*b

:-)

-- 
Wojtek :-)

Wojtek wrote:
> Patricia Shanahan wrote :
>> Addable, Multipliable, etc. become marker interfaces. Suppose a is a
>> reference to Multipliable or a type implementing Multipliable. Then the
>> compiler would process a+b as though it were 
>> a.multiplicationOperation(b).
> 
> I really like this. It merges operator overloading with a very strong 
> suggestion that this is only a mathematical operation.
> 
> So to pervert this by making the plus sign do something bizzare would 
> take a really large ego.
> 
> Um, though a+b should be a*b
> 
> :-)
> 

That's what comes of switching examples from addition to multiplication
without sufficient proof reading. :-(

We could deal with e.g. double * Matrix by allowing declaration of a
method rhsMultiplationOperator.

For a*b, if a is not Multipliable or there is no applicable, accessible
method for a.multiplicationOperator(b) then check b. If b is
Multipliable, treat a*b as b.rhsMultiplicationOperator(a).

For a commutative operation, that might be implemented as:

Matrix rhsMultiplicationOperator(double left){
   return multiplicationOperator(left);
}

I don't really like the method name. Suggestions?

Patricia

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-837489031-1211904890=:20026
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 27 May 2008, Patricia Shanahan wrote:

> Tom Anderson wrote:
>> On Mon, 26 May 2008, Patricia Shanahan wrote:
>> 
>>> Wojtek wrote:
>>>> Arne Vajh�j wrote :
>>>>> Operators only make the code more readable for classic arithmetic.
>>>> 
>>>> Which is my point.
>>> 
>>> Maybe this subthread suggests a solution. Define, for example, an
>>> interface Addable<T> with
>>> 
>>> T additionOperation(T o);
>>> 
>>> as its only method.
>> 
>> Analogising to multiplication, this is going to make it impossible to write 
>> my Matrix class which can be multiplied any of a double, a Vector, or 
>> another Matrix, because you can't implement multiple instances of a generic 
>> interface. Well, you could, but you'd have to do an instanceof switch 
>> inside additionOperation, or implement some kind of ugly bounce dispatch.
>> 
>> Anyway, i'm not happy with this solution, although i appreciate and 
>> strongly agree with its intent.
>
> Good point. How about this modification?
>
> Addable, Multipliable, etc. become marker interfaces. Suppose a is a 
> reference to Multipliable or a type implementing Multipliable. Then the 
> compiler would process a+b as though it were 
> a.multiplicationOperation(b).

I'm happy with this. What you describe is exactly how it works in python 
or C++, with a slightly different method name, and requiring a marker 
interface. Could we even drop the marker interface? What do we gain by 
having it?

If you're talking about handling this as a rewrite rule, then the type of 
the receiver variable would have to have a suitable multiplication method. 
You couldn't multiply a plain Multipliable, but overloading would work. 
That's fine by me.

The alternative to doing it by rewriting would be to do a fully dynamic 
invocation, but that's clearly madness, and doesn't preserve type safety, 
eg:

Multipliable m = new Matrix(23, 17) ;
Object result = m * new GaloisField(7).getElement(5) ; // O NOES!

tom

-- 
Any problem in computer science can be solved with another layer of
indirection. -- David Wheeler
---910079544-837489031-1211904890=:20026--

On Tue, 27 May 2008, Patricia Shanahan wrote:

>> Patricia Shanahan wrote :
>>> Addable, Multipliable, etc. become marker interfaces. Suppose a is a
>>> reference to Multipliable or a type implementing Multipliable. Then the
>>> compiler would process a+b as though it were a.multiplicationOperation(b).
>
> We could deal with e.g. double * Matrix by allowing declaration of a
> method rhsMultiplationOperator.
>
> For a*b, if a is not Multipliable or there is no applicable, accessible
> method for a.multiplicationOperator(b) then check b. If b is
> Multipliable, treat a*b as b.rhsMultiplicationOperator(a).
>
> For a commutative operation, that might be implemented as:
>
> Matrix rhsMultiplicationOperator(double left){
>  return multiplicationOperator(left);
> }
>
> I don't really like the method name. Suggestions?

rotarepOnoitacilpitlum()?

I quite like that it starts with 'rotare', which sounds like a latin verb 
for rotating something.

FWIW, python calls this __rmul__, where normal multiplication is __mul__.

I'd suggest multiply and rightMultiply as the names.

tom

-- 
Any problem in computer science can be solved with another layer of
indirection. -- David Wheeler

Wojtek wrote:
> Patricia Shanahan wrote :
>> Addable, Multipliable, etc. become marker interfaces. Suppose a is a
>> reference to Multipliable or a type implementing Multipliable. Then the
>> compiler would process a+b as though it were 
>> a.multiplicationOperation(b).
> 
> I really like this. It merges operator overloading with a very strong 
> suggestion that this is only a mathematical operation.
> 
> So to pervert this by making the plus sign do something bizzare would 
> take a really large ego.
> 
> Um, though a+b should be a*b
> 
> :-)
> 
What about @Annotations instead?

public class Foo {

    @AdditionOperation
    Foo anyMethodIWant(Foo foo) {...}

    @AdditionOperation
    Foo addInteger(int foo) {...}

    @MultiplicationOperation
    Bar multiplyFooIntoBar(Foo foo) {...}
}

foo*foo would then become foo.muliplyFooIntoBar(foo), and foo+3 becomes 
foo.addInteger(3); where foo+anotherFoo becomes 
foo.anyMethodIWant(anotherFoo);

Problems may arise with commutative vs non-commutative operations... 
Hmm, now that I think about it. having operators be instance methods 
doesn't necessarily work... It might be that we would need to use static 
imports in combination with annotations for it to work well.

-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts wrote:
> Wojtek wrote:
>> Patricia Shanahan wrote :
>>> Addable, Multipliable, etc. become marker interfaces. Suppose a is a
>>> reference to Multipliable or a type implementing Multipliable. Then the
>>> compiler would process a+b as though it were 
>>> a.multiplicationOperation(b).
>>
>> I really like this. It merges operator overloading with a very strong 
>> suggestion that this is only a mathematical operation.
>>
>> So to pervert this by making the plus sign do something bizzare would 
>> take a really large ego.
>>
>> Um, though a+b should be a*b
>>
>> :-)
>>
> What about @Annotations instead?
> 
> public class Foo {
> 
>    @AdditionOperation
>    Foo anyMethodIWant(Foo foo) {...}

This loses the property that I think may make this relatively
non-controversial, the requirement that the method be declared to be
additionOperation. The people who dislike operator overloading seem to
believe that programmers are more likely to declare a "+" operation that
has nothing to do with addition than an addition method that has nothing
to do with addition.

Patricia

Tom Anderson wrote:
> On Tue, 27 May 2008, Patricia Shanahan wrote:
> 
>> Tom Anderson wrote:
>>> On Mon, 26 May 2008, Patricia Shanahan wrote:
>>>
>>>> Wojtek wrote:
>>>>> Arne Vajh�j wrote :
>>>>>> Operators only make the code more readable for classic arithmetic.
>>>>>
>>>>> Which is my point.
>>>>
>>>> Maybe this subthread suggests a solution. Define, for example, an
>>>> interface Addable<T> with
>>>>
>>>> T additionOperation(T o);
>>>>
>>>> as its only method.
>>>
>>> Analogising to multiplication, this is going to make it impossible to 
>>> write my Matrix class which can be multiplied any of a double, a 
>>> Vector, or another Matrix, because you can't implement multiple 
>>> instances of a generic interface. Well, you could, but you'd have to 
>>> do an instanceof switch inside additionOperation, or implement some 
>>> kind of ugly bounce dispatch.
>>>
>>> Anyway, i'm not happy with this solution, although i appreciate and 
>>> strongly agree with its intent.
>>
>> Good point. How about this modification?
>>
>> Addable, Multipliable, etc. become marker interfaces. Suppose a is a 
>> reference to Multipliable or a type implementing Multipliable. Then 
>> the compiler would process a+b as though it were 
>> a.multiplicationOperation(b).
> 
> I'm happy with this. What you describe is exactly how it works in python 
> or C++, with a slightly different method name, and requiring a marker 
> interface. Could we even drop the marker interface? What do we gain by 
> having it?
....

The marker interface avoids any backwards compatibility problems with a
method called "additionOperation" that is not intended to be used to
implement "+".

Patricia

Tom Anderson wrote:
> On Tue, 27 May 2008, Patricia Shanahan wrote:
> 
>>> Patricia Shanahan wrote :
>>>> Addable, Multipliable, etc. become marker interfaces. Suppose a is a
>>>> reference to Multipliable or a type implementing Multipliable. Then the
>>>> compiler would process a+b as though it were 
>>>> a.multiplicationOperation(b).
>>
>> We could deal with e.g. double * Matrix by allowing declaration of a
>> method rhsMultiplationOperator.
>>
>> For a*b, if a is not Multipliable or there is no applicable, accessible
>> method for a.multiplicationOperator(b) then check b. If b is
>> Multipliable, treat a*b as b.rhsMultiplicationOperator(a).
>>
>> For a commutative operation, that might be implemented as:
>>
>> Matrix rhsMultiplicationOperator(double left){
>>  return multiplicationOperator(left);
>> }
>>
>> I don't really like the method name. Suggestions?
> 
> rotarepOnoitacilpitlum()?
> 
> I quite like that it starts with 'rotare', which sounds like a latin 
> verb for rotating something.
> 
> FWIW, python calls this __rmul__, where normal multiplication is __mul__.
> 
> I'd suggest multiply and rightMultiply as the names.

The issue with simple names such as "multiply" is classes such as
BigDecimal that already use them, but should implement Multipliable.
Would it be good or bad to automatically turn those methods into
operator implementations?

Patricia

Patricia Shanahan wrote:

>>    Foo anyMethodIWant(Foo foo) {...}
> 
> This loses the property that I think may make this relatively
> non-controversial, the requirement that the method be declared to be

 From my personal perspective, you've already lost that, because an 
interface can be added to any class.  That's rather more abusable than 
I'd prefer.

One root class, abstract or otherwise, is less abusable, in my opinion.

public abstract class AbstractNumber {

   public abstract AbstractNumber multiply( AbstractNumber n );
   public abstract AbstractNumber divide( AbstractNumber n );
   // etc.

}

Now you can still abuse this and derive things from AbstractNumber that 
really aren't abstract numbers, but that can't be helped.  What you 
can't do is something like:

class MyList extends AbstractList implements Addable {

   // abuse city

}

So by using one root class, operator overloading can't be add willy 
nilly to any class.  It's confined to descendants of AbstractNumber (and 
maybe something like AbstractMatrix).

I know those of you still debating this don't really agree with that, 
I'm just waving my little not-so-much-operator-overloading flag around, 
just to show it's still here. :)

Tom Anderson wrote:
....
> If you're talking about handling this as a rewrite rule, then the type 
> of the receiver variable would have to have a suitable multiplication 
> method. You couldn't multiply a plain Multipliable, but overloading 
> would work. That's fine by me.
> 
> The alternative to doing it by rewriting would be to do a fully dynamic 
> invocation, but that's clearly madness, and doesn't preserve type 
> safety, eg:
> 
> Multipliable m = new Matrix(23, 17) ;
> Object result = m * new GaloisField(7).getElement(5) ; // O NOES!

My intention is that the compiler would apply the normal method
invocation rules after rewriting a*b to a.multiplyOperation(b). That
allows for overloading and inheritance, but in a way that is already
familiar. I don't think Matrix would declare or inherit a
multiplyOperation method that takes a GaloisField element parameter.

Patricia

Mark Space wrote:
> Patricia Shanahan wrote:
> 
>>>    Foo anyMethodIWant(Foo foo) {...}
>>
>> This loses the property that I think may make this relatively
>> non-controversial, the requirement that the method be declared to be
> 
>  From my personal perspective, you've already lost that, because an 
> interface can be added to any class.  That's rather more abusable than 
> I'd prefer.

Stress *relatively* non-controversial.

> 
> One root class, abstract or otherwise, is less abusable, in my opinion.
> 
> public abstract class AbstractNumber {
> 
>   public abstract AbstractNumber multiply( AbstractNumber n );
>   public abstract AbstractNumber divide( AbstractNumber n );
>   // etc.
> 
> }
....

How would you relate AbstractNumber to the existing java.lang.Number?
Would AbstractNumber be a superclass or subclass of Number?

Patricia

Patricia Shanahan wrote:

> 
> Stress *relatively* non-controversial.

No worries.


> How would you relate AbstractNumber to the existing java.lang.Number?
> Would AbstractNumber be a superclass or subclass of Number?

Well, I haven't thought about this carefully, so I'm not sure of all the 
ramification.  So I don't think I feel comfortable at this time 
proposing changing the hierarchy of existing classes.

Sun seems close to modifying their compiler for Java 7 to perform some 
magic on the BigInteger and BigDecimal classes to allow infix operators 
for * + - / and % (I think % too).  That's good enough for me.

What I think I'd propose is to add a new class which inherits from 
java.lang.Number, called AbstractNumber, and let folks who want to do 
their own operator overloading make new classes descended from that class.

This way absolutely nothing changes, except for one new class that gets 
added.  Byte, Integer, Double, etc. get a new sibling class, 
AbstractNumber, and that's it.  Except that AbstractNumber is also 
special, like BigInteger and BigDecimal, and the compiler will also do 
some magic on it's descendants to allow the proposed 5 infix operators.

And we might add AbstractMatrix descended from AbstractNumber for [] 
too, but that appears to be a tad more controversial.  It would however, 
make the semantic of using [] distinct from any use of [] on Collections.

Just my 2 pennies.

Mark Space wrote:
> Patricia Shanahan wrote:
> 
>>
>> Stress *relatively* non-controversial.
> 
> No worries.
> 
> 
>> How would you relate AbstractNumber to the existing java.lang.Number?
>> Would AbstractNumber be a superclass or subclass of Number?
> 
> Well, I haven't thought about this carefully, so I'm not sure of all the 
> ramification.  So I don't think I feel comfortable at this time 
> proposing changing the hierarchy of existing classes.
> 
> Sun seems close to modifying their compiler for Java 7 to perform some 
> magic on the BigInteger and BigDecimal classes to allow infix operators 
> for * + - / and % (I think % too).  That's good enough for me.
> 
> What I think I'd propose is to add a new class which inherits from 
> java.lang.Number, called AbstractNumber, and let folks who want to do 
> their own operator overloading make new classes descended from that class.
> 
> This way absolutely nothing changes, except for one new class that gets 
> added.  Byte, Integer, Double, etc. get a new sibling class, 
> AbstractNumber, and that's it.  Except that AbstractNumber is also 
> special, like BigInteger and BigDecimal, and the compiler will also do 
> some magic on it's descendants to allow the proposed 5 infix operators.
> 
> And we might add AbstractMatrix descended from AbstractNumber for [] 
> too, but that appears to be a tad more controversial.  It would however, 
> make the semantic of using [] distinct from any use of [] on Collections.
> 
> Just my 2 pennies.
> 
> 
Sure, but that doesn't work well with Complex numbers or other 
fields/rings/groups that aren't real-numbers.
It also doesn't work well with things that yield different types than 
themselves for these operators. (vector multiplication for instance)


-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Mark Space wrote:
....
> What I think I'd propose is to add a new class which inherits from 
> java.lang.Number, called AbstractNumber, and let folks who want to do 
> their own operator overloading make new classes descended from that class.
....

That would force concrete classes inheriting from AbstractNumber to
provide all the methods in Number. What is the doubleValue() of a
matrix?

Patricia

Patricia Shanahan wrote:
> Mark Space wrote:
> ...
>> What I think I'd propose is to add a new class which inherits from 
>> java.lang.Number, called AbstractNumber, and let folks who want to do 
>> their own operator overloading make new classes descended from that 
>> class.
> ...
> 
> That would force concrete classes inheriting from AbstractNumber to
> provide all the methods in Number. What is the doubleValue() of a
> matrix?


A good point.  Do you think it would be better to derive AbstractNumber 
directly from Object?

However, here's a guess how doubleValue() might be implemented for a matrix:

All of the methods in java.lang.Number are identities.  The 
doubleValue() of a Byte with a value of 1 is still 1, insofar as a 
double is able to represent the value of 1.

To me, this means that an Matrix which is implemented with, say, floats, 
should return a Matrix implemented with doubles when doubleValue() is 
called on it.  Not all of these conversions make sense to me.  I don't 
see the point of a Matrix which is created with byteValue(), for example.

So I guess AbstractNumber could attempt to hide the conversion methods 
something like this:

  abstract public AbstractNumber doubleValue();

But I don't think this is even a legal syntax, let alone good idea. (I'm 
not even going to recheck the JLS for syntax.)  Because regardless, it 
could give the compiler fits trying to pick out the correct method.

So maybe just deriving AbstractNumber from Object, and re-implementing 
the conversion methods with a correct signature, is the better idea. 
That's a bummer, because I really wanted to add the new as sib of the 
other Number classes -- it would show up at the right spot in the Java 
doc automagically.  But I guess one more "see also" in the Java doc 
won't kill anybody.

Daniel Pitts wrote:

> Sure, but that doesn't work well with Complex numbers or other 
> fields/rings/groups that aren't real-numbers.
> It also doesn't work well with things that yield different types than 
> themselves for these operators. (vector multiplication for instance)
> 
> 

How so?

Mark Space wrote:
> Patricia Shanahan wrote:
>> Mark Space wrote: ...
>>> What I think I'd propose is to add a new class which inherits
>>> from java.lang.Number, called AbstractNumber, and let folks who
>>> want to do their own operator overloading make new classes
>>> descended from that class.
>> ...
>> 
>> That would force concrete classes inheriting from AbstractNumber to
>>  provide all the methods in Number. What is the doubleValue() of a 
>> matrix?
> 
> 
> A good point.  Do you think it would be better to derive
> AbstractNumber directly from Object?

I don't think it should be done with "extends" at all. I believe base
class extension was seriously over-used in the early days of Java, and
should be limited to situations in which there is inheritance of
implementation.

However, I am curious about whether it *can* be done using extends. The
relationship to Number is tricky, because Number has a strong flavor of
real number subset. Some, but not all, of the arithmetic classes do
represent subsets of the reals, and so should extend Number.

> However, here's a guess how doubleValue() might be implemented for a
> matrix:
> 
> All of the methods in java.lang.Number are identities.  The
> doubleValue() of a Byte with a value of 1 is still 1, insofar as a
> double is able to represent the value of 1.

Double can represent 1 exactly. But it does not work the other way
round. The byteValue() of new Integer(1000) has very little connection
to 1000, and will not convert back to it.

 > To me, this means that an Matrix which is implemented with, say,
 > floats, should return a Matrix implemented with doubles when
 > doubleValue() is called on it.  Not all of these conversions make
 > sense to me.  I don't see the point of a Matrix which is created with
 > byteValue(), for example.

The doubleValue() method in class Number returns a double, so any
concrete class that extends it, directly or indirectly, must declare or
inherit a public doubleValue() method that returns a double.

On the other hand, if AbstractNumber does not extend Number, there is no
reason for it to have a doubleValue method at all. Why couple arithmetic
operations with an arbitrary set of conversions?

Patricia

Patricia Shanahan wrote:

> On the other hand, if AbstractNumber does not extend Number, there is no
> reason for it to have a doubleValue method at all. Why couple arithmetic
> operations with an arbitrary set of conversions?
>

I think I agree with that.

Mark Space wrote:
> Patricia Shanahan wrote:
> 
>> On the other hand, if AbstractNumber does not extend Number, there is no
>> reason for it to have a doubleValue method at all. Why couple arithmetic
>> operations with an arbitrary set of conversions?
>>
> 
> I think I agree with that.
> 

Number is really about being convertible to real number subset types,
such as int and double. Your AbstractNumber is about having arithmetic
operations implemented as methods.

To me, those seem completely orthogonal features. A class may have both,
neither, or one of them without having the other. Given single
inheritance, there is no way to represent that in the "extends" hierarchy.

I think your AbstractNumber has to be an interface, rather than a class.

Patricia