operator overloading
josh
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
Leonard Milcin
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
Leonard Milcin
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
josh
> 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);
Leonard Milcin
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
--
Tom Anderson
> 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
Owen Jacobson
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)
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 = ..., b = ...;
Interval duration = a - b;
and not
Instant difference = a - b;
Similarly, I'd want
Instant a = ...;
Interval b = ...;
Instant future = a + b; // or b + a
Some points to consider...
-o
RedGrittyBrick
> Tom Anderson <tw...@urchin.earth.li> quotes:
>>>> Time t3 = t + t2;
>
> 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
Andrea Francia
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
Tom Anderson
> Supersedes: <plus-2008...@ram.dialup.fu-berlin.de>
>
> Tom Anderson <tw...@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 Anderson
> 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.
Joshua Cranmer
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
Joshua Cranmer
> 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.
Joshua Cranmer
> 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.
Roedy Green
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
Patricia Shanahan
> On Thu, 8 May 2008 04:47:53 -0700 (PDT), josh <xdeve...@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
Owen Jacobson
> 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 +=; 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.)
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 >, <, <=, 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.
-o
Tom Anderson
> Joshua Cranmer <Pidg...@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
Tom Anderson
> On Thu, 8 May 2008 04:47:53 -0700 (PDT), josh <xdeve...@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 Anderson
> 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.
Daniel Dyer
wrote:
> On Thu, 8 May 2008, Roedy Green wrote:
>
>> On Thu, 8 May 2008 04:47:53 -0700 (PDT), josh <xdeve...@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
Tom Anderson
> 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 Anderson
> Tom Anderson <tw...@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.
Owen Jacobson
> 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. 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 +=; 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. Large isn't *necessarily* slow, if you're
clever.
> 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. 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> {
> > 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.
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?
josh
> On Fri, 09 May 2008 00:48:48 +0100, Tom Anderson <t...@urchin.earth.li>
> wrote:
>
>
>
>
>
> > On Thu, 8 May 2008, Roedy Green wrote:
>
> >> 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.
>
> --
>
> - 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
Nigel Wade
> Supersedes: <plus-2008...@ram.dialup.fu-berlin.de>
>
> Tom Anderson <tw...@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
Tom Anderson
> 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
Thomas Schodt
> 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.
>
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.
Lew
> 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
Lew
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
Patricia Shanahan
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
Tom Anderson
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
Joshua Cranmer
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.
Joshua Cranmer
> 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!
Tom Anderson
> 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
John W Kennedy
> 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"
Mark Space
> 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....
Mark Space
> Hi,
>
> I don't find any document that say if the operator overloading will be
> a new feature of the Java 7
>
>
> Thanks
It looks like BigNum might be allowed to use operators next....
Kevin McMurtrie
Mark Space <mark...@sbc.global.net> wrote:
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.
Lew
> 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
Thomas Schodt
> 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.
Tom Anderson
> 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!
Tom Anderson
> 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.
Arved Sandstrom
news:Pine.LNX.4.64.08...@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 ...
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
Arved Sandstrom
>
>> 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
Patricia Shanahan
...
> 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
Patricia Shanahan
...
> 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
Mark Space
>
> 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...
Mark Space
>> 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!
Arne Vajhøj
> 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
Mark Thornton
> 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
Mark Space
> Patricia Shanahan <pa...@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?
>
>
> 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.
Daniel Dyer
wrote:
> Stefan Ram wrote:
>> Patricia Shanahan <pa...@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
Mark Thornton
>> 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
Lew
> 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
Lew
>> 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
Patricia Shanahan
...
> 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
Patricia Shanahan
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
Mark Space
>
> 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.
Patricia Shanahan
...
> 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
John W Kennedy
> On Fri, 9 May 2008, Mark Space wrote:
>>
>> 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"
Arne Vajhøj
> 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
Mark Thornton
> Mark Thornton <mtho...@optrak.co.uk> writes:
>> Unfortunately performance is terrible. Not exactly suitable for
>> serious maths.
>
> 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
Mark Thornton
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
Andreas Leitgeb
> 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
Tom Anderson
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!!!
Tom Anderson
> 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 Anderson
> 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.
Patricia Shanahan
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
Lew
> Mark Space <mark...@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
Lew
> "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
Patricia Shanahan
>> Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.
>
>
> »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
Mark Space
> 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. ;)
Tom Anderson
> 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
Patricia Shanahan
> 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
Andreas Leitgeb
> 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)
Andreas Leitgeb
> 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.
Andreas Leitgeb
> 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 :-)
Lew
> 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
Lew
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
Lew
>> 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
Arved Sandstrom
news:acKdnTADa6myqrXV...@comcast.com...
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.
Mark Thornton
>
> 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
Andreas Leitgeb
> Mark Space <mark...@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...
Tom Anderson
> Tom Anderson <tw...@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
Andreas Leitgeb
> 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.
Andreas Leitgeb
> 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"!
Arne Vajhøj
> Arne Vajhřj wrote:
>> John W Kennedy wrote:
>>> 1962, actually. Logical operators first appeared in FORTRAN IV.
>>
>> 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
Mark Space
> 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.
Mark Space
> 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?
Lew
> 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