grauzone wrote:
This has happened before. Somehow Java has this penchant for
attracting odd groupies. Pretty much every feature that Java didn't
have was vilified by zealots until adoption, when all of a sudden it
became a brilliant decision.
D has this too.
Probably a lot of language enthu
This has happened before. Somehow Java has this penchant for attracting
odd groupies. Pretty much every feature that Java didn't have was
vilified by zealots until adoption, when all of a sudden it became a
brilliant decision.
D has this too.
Edward Diener wrote:
Paul D. Anderson wrote:
Sounds like someone needs a strong dose of D!!
http://java.dzone.com/articles/why-java-doesnt-need-operator
The comments bounce between "operator overloading is always bad
because you can do idiotic things with it" and "operator overloading
is ess
Paul D. Anderson wrote:
Sounds like someone needs a strong dose of D!!
http://java.dzone.com/articles/why-java-doesnt-need-operator
The comments bounce between "operator overloading is always bad because you can do idiotic
things with it" and "operator overloading is essential because sometime
On 16/04/2009 15:47, Daniel Keep wrote:
Yigal Chripun wrote:
On 15/04/2009 18:50, BCS wrote:
Hello Yigal,
sounds silly to me. Why not simply generalize and allow
defining in-fix functions like in functional languages? that
also includes allowing any unicode character[s].
lexing and (more i
Yigal Chripun wrote:
> Why not simply generalize and allow defining in-fix
> functions [...]?
This would transform the current set of operators into a special case.
Please illustrate how you want to embed this special case into the
generalization.
-manfred
Yigal Chripun wrote:
> On 15/04/2009 18:50, BCS wrote:
>> Hello Yigal,
>>
>>
>>> sounds silly to me. Why not simply generalize and allow defining
>>> in-fix functions like in functional languages? that also includes
>>> allowing
>>> any unicode character[s].
>>
>> lexing and (more importantly) pa
Don wrote:
> Walter Bright wrote:
>> My problem with operator overloading stemmed from C++'s endorsement of
>> using >> and << for stream operations.
>
> I saw someone who wrote a database library, and used << and >> for
> stream operations. Then he needed a second form of stream operations, so
Don wrote:
The number of operators that you can overload is very small and each of
them is attached to very specific semantics that makes little sense
outside the realm of scalars and of a few other specialized mathematical
concepts (e.g. matrices).
Exactly right.
Bingo! That's what operator
Don wrote:
Walter Bright wrote:
My problem with operator overloading stemmed from C++'s endorsement of
using >> and << for stream operations.
I saw someone who wrote a database library, and used << and >> for
stream operations. Then he needed a second form of stream operations, so
he overloa
Don wrote:
Paul D. Anderson wrote:
Sounds like someone needs a strong dose of D!!
http://java.dzone.com/articles/why-java-doesnt-need-operator
The comments bounce between "operator overloading is always bad
because you can do idiotic things with it" and "operator overloading
is essential bec
bearophile Wrote:
> Paul D. Anderson:
>
> Having some operator overload is good if you write some numerical/scientific
> code. Try working with bignumbers or vectors in Java, and you will see how
> quickly some otherwise simple expressions become an unreadable mess.
>
> Bye,
> bearophile
I ag
On 15/04/2009 18:50, BCS wrote:
Hello Yigal,
sounds silly to me. Why not simply generalize and allow defining
in-fix functions like in functional languages? that also includes
allowing
any unicode character[s].
lexing and (more importantly) parsing become a major problem if you
allow that
Hello Yigal,
sounds silly to me. Why not simply generalize and allow defining
in-fix functions like in functional languages? that also includes allowing
any unicode character[s].
lexing and (more importantly) parsing become a major problem if you allow that
On 15/04/2009 18:25, Jarrett Billingsley wrote:
On Wed, Apr 15, 2009 at 10:31 AM, Robert Fraser
wrote:
bearophile wrote:
Are there few non-arithmetic operators (that will support operator
overloading too) with a clear semantics that can be added to D?
a ♥ b
opLove.
sounds silly to me. W
On Wed, Apr 15, 2009 at 10:31 AM, Robert Fraser
wrote:
> bearophile wrote:
>>
>> Are there few non-arithmetic operators (that will support operator
>> overloading too) with a clear semantics that can be added to D?
>
> a ♥ b
>
opLove.
bearophile wrote:
Are there few non-arithmetic operators (that will support operator overloading
too) with a clear semantics that can be added to D?
a ♥ b
bearophile wrote:
Don:
**Don't overload arithmetic operators unless you are doing arithmetic.**<
Are there few non-arithmetic operators (that will support operator overloading
too) with a clear semantics that can be added to D?
The main problems here are that such operators are very few, they
Don:
>**Don't overload arithmetic operators unless you are doing arithmetic.**<
Are there few non-arithmetic operators (that will support operator overloading
too) with a clear semantics that can be added to D?
The main problems here are that such operators are very few, they may end being
used
Paul D. Anderson wrote:
Sounds like someone needs a strong dose of D!!
http://java.dzone.com/articles/why-java-doesnt-need-operator
The comments bounce between "operator overloading is always bad because you can do idiotic
things with it" and "operator overloading is essential because sometime
Walter Bright wrote:
My problem with operator overloading stemmed from C++'s endorsement of
using >> and << for stream operations.
I saw someone who wrote a database library, and used << and >> for
stream operations. Then he needed a second form of stream operations, so
he overloaded > and <.
Paul D. Anderson:
Having some operator overload is good if you write some numerical/scientific
code. Try working with bignumbers or vectors in Java, and you will see how
quickly some otherwise simple expressions become an unreadable mess.
Bye,
bearophile
Walter Bright wrote:
My problem with operator overloading stemmed from C++'s endorsement of
using >> and << for stream operations.
You know, I never knew << meant bit shifting until my assembly course at
university!!
On Wed, 15 Apr 2009 02:29:33 +0200, Rainer Deyke wrote:
Walter Bright wrote:
My problem with operator overloading stemmed from C++'s endorsement of
using >> and << for stream operations.
I don't see how "stream << value" is any worse than "shift_left(stream,
value)".
Most operators are just
Walter Bright wrote:
> My problem with operator overloading stemmed from C++'s endorsement of
> using >> and << for stream operations.
I don't see how "stream << value" is any worse than "shift_left(stream,
value)".
Most operators are just functions with special syntax. No more, no
less. The is
My problem with operator overloading stemmed from C++'s endorsement of
using >> and << for stream operations.
Paul D. Anderson wrote:
Sounds like someone needs a strong dose of D!!
http://java.dzone.com/articles/why-java-doesnt-need-operator
The comments bounce between "operator overloading is always bad because you can do idiotic
things with it" and "operator overloading is essential because sometime
Paul D. Anderson wrote:
Sounds like someone needs a strong dose of D!!
http://java.dzone.com/articles/why-java-doesnt-need-operator
The comments bounce between "operator overloading is always bad because you can do idiotic
things with it" and "operator overloading is essential because sometime
Sounds like someone needs a strong dose of D!!
http://java.dzone.com/articles/why-java-doesnt-need-operator
The comments bounce between "operator overloading is always bad because you can
do idiotic things with it" and "operator overloading is essential because
sometimes you really need it".
H
29 matches
Mail list logo
