You know, your post made me think of this construct:
using ( new MatrixVectorAlgebra() ) {
Matrix result = matrix * vector;
}
using ( new ExactMath() ) {
BigInteger i = 10 * foobar;
}
the algebra controls both how literals get translated, and the
meanings of all operators. Just throwing it out there. I'll need to
think on it _a lot_ more, and it has the disadvantage that any given
snippet of code is pretty much meaningless unless you know the algebra
context that goes with it, but then that's kind of true for any
sufficiently complex snippet (the need to know context), and its
certainly true when using operator overloading - you'd need to know
the type of the LHS before you know what the operator would do, in for
example python. So that seems like an acceptable price to pay.
Could be overkill, though. Feels very fortressy.
On Aug 17, 2:03 am, Peter Becker <[email protected]> wrote:
> To twist the thread a bit more: IMO the whole idea of having an operator
> with mixed types on a class is bad. So is having the
> Matrix.multiply(Vector) method. The Matrix-Vector product (left or
> right) is not intrinsic to either type, it is part of a larger algebra.
>
> Unfortunately OO won the market to an extent where sanity was lost :-)
>
> Operator definitions make much more sense when they are seen as part of
> an algebra and not hacked onto OO structures. If you want to do them on
> polymorphic structures with mixed types you probably need to have
> multiple dispatch in your runtime environment.
>
> Peter
>
>
>
> Jess Holle wrote:
> > I've certainly used operator overloading myself for graphics matrix math.
>
> > That said, I don't see how it "speeds up execution". It just reduces
>
> > vector2 = matrix.multiply( vector1 );
>
> > to
>
> > vector2 = matrix * vector1;
>
> > Nice example of clear and concise (and appropriate) use of operator
> > overloading -- but not of execution speed improvement.
>
> > --
> > Jess Holle
>
> > Casper Bang wrote:
> >> With all due respect, operator overloading in Fan is an entirely
> >> different, much less scary beast than the infamous C++ implementation
> >> which everyone seems to have in mind. I'm not much for guns, but to
> >> continue gun metaphor: Python and C# both demonstrates that this is
> >> not necessarily an exploding Uzi. But if your premise is that
> >> programmers will do bad things when given the slightest chance, then
> >> remember that you don't actually need a gun to kill somebody - it just
> >> gets the job done easier and faster.
>
> >> Btw. just yesterday I witnessed an example of how operator overloading
> >> simplifies code and speeds up execution:
> >>http://blog.joa-ebert.com/2009/08/10/flirting-with-silverlight/
>
> >> /Casper
>
> >> On 13 Aug., 13:20, Ben Schulz <[email protected]> wrote:
>
> >>>> So operator overloading is bad because people have HR problems?
>
> >>> Why stop at operator overloading? To hell with all safe guards.. No
> >>> more speed limits or safty belts; let's everyone just drive
> >>> reasonably. And what's with architects and statics? It'll hold.
>
> >>>> Don't blame the gun, blame the shooter.
>
> >>> Yes, because *that's* how you bring people back from the dead.
>
> >>> With kind regards
> >>> Ben
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
