[fpc-devel] Proposal: Enhanced replacement for assignment operators

["Vinzent Höfler"]

Alexander Klenin <klenin at gmail.com>:

> On Sat, Aug 7, 2010 at 04:59, "Vinzent Höfler"
> <JeLlyFish.software at gmx.net> wrote:
> > Alexander Klenin <klenin at gmail.com>:
> >
> > Except for the ">=" "<=" the resulting error would not compile in most
> cases. THAT's the difference.
> 
> I thought we were talking about reading errors, not writing errors?

If you'd like to think so. ;) I am talking about readability and that also means "spotting the actual bug" - which may be a typo being made in the first place.

A bug spotted by the compiler is a bug not needing to be found with the debugger.

> >> Code bloat/duplication is much more serious.
> >> It is usually not just SomeReallyLongVariableNameY, but something like:
> >> SomeFunctionReturningObject(param1, param2).PointArrayField[i] +=
> >> FunctionReturningPointOffset(param);
> >> Try rewriting that without "+=".
> >
> > Add (SomeFunctionReturningObject (param1, param2).PointArrayField[i],
> >     FunctionReturningPointOffset (param));
> 
> Exactly, and so we are back to square one -- you accumulate integers with
> "Inc",
> points with "AddPoint", doubles with "FloatInc", write extraneous
> four-line wrapper for every type and always forget which of
> MultVector and VecMultiply is procedure, and which is function.

Well, if you do it that way... I'd use overloading and use the same name (or, admitted, even the same operator) for the same concept.

> > IMO, since the invention of subroutines, the expressive power of
> operators is overestimated. Consistently.
> 
> Ok, here is a real code from one of my Delphi 7 projects:
> 
>   mu :=
>     MatrixMultiplyVector(
>       InverseCoordMatrix(
>         CoordMatrixAdd(
>           CoordMatrixScale(dst.A, w), CoordMatrixScale(ASource.A, AWeight)
>         ),
>       ),
>       VectorAdd(
>         VectorScale(MatrixMultiplyVector(dst.A, dst.Mu), w),
>         VectorScale(
>           MatrixMultiplyVector(ASource.A, ASource.Mu), AWeight)
>       ),
>     );
>   a :=
>     CoordMatrixScale(
>       CoordMatrixAdd(
>         CoordMatrixScale(dst.A, w), CoordMatrixScale(ASource.A, AWeight)
>       ),
>       1 / (w + AWeight)
>     );
> 

If you'd used just Add, Scale, and Multiply the code may be slightly more readable. :P

> Here is the same code after upgrading:
> 
>   mu :=
>       InverseCoordMatrix(w * dst.A + AWeight * ASource.A) *
>       (w * dst.A * dst.Mu + AWeight * ASource.A * ASource.Mu);
>   a := w * dst.A + AWeight * ASource.A / (w + AWeight);
> 
> [Both versions slightly simplified to avoid overbloating the message].
> Believe me, expressive power of operators is severely underestimated
> by those who did not try to do calculations without them ;-)

Believe me, after all those years I still know what I am talking about. :) And why didn't you overload "-" for "Inverse"?

Surely, I didn't want to negate the fact that operator overloading can solve some problems, but why the hell does it always have to be the "add/sub/div/mul/mod/$whatever and assign" operator? Oh, this one doesn't exist at all, because it's two actions in one? My bad. Why didn't I think of the "multiply and add" operator, which was very common in DSPs once and meanwhile made it to mainstream CPUs? "*+:=" would be a proper symbol for it, wouldn't it?

So, I still do not find an occasion of a "reverse polish assignment" in this example. I even don't see what part of this example it would make more readable. Well, maybe it's just my eyes...


Vin"Sarcasm included."zent.

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01