On Mon, 1 Feb 2016, Maciej Izak wrote:

2016-02-01 10:17 GMT+01:00 Michalis Kamburelis <michalis.ka...@gmail.com>:

As far as I understand, compatibility is not broken: new IfThen was
deliberately introduced as part of the System unit, that is implicitly
always used as the 1st unit. If you use Math (or StrUtils or any other
modules that provide IfThen implementations), they will "cover" the
System.IfThen definition. So your code will continue to work as it was.

And the name like FpIfThen look rather ugly, actually. As far as I'm
concerned, IfThen sounds simple and Ok.


IfThen is not ok. It can potentially break compatibility. The probability
is huge. IfThen is in many cases the only function that is used from Math
or StrUtils. I have big codebase to maintain which is refactored very
often. The risk to omit Math and StrUtils is very big.

This is not an argument.

If you take this as an argument, then the system unit is set in concrete,
for fear of breaking someones code whenever something new is introduced.


It can be very hard to debug.

There are so many ways to implement this and was chosen the worst scenario.
:\

From my point of view, Sven took the best possible route by making it an
identifier of the system unit. The refactoring argument is nonsense, as it
applies to ANY identifier, not just this one.

We can discuss IIF or IfThen, but the same applies for IIF.

Michael.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to