[fpc-pascal] Re: StrUtils.RomanToInt oddities

[Reinier Olislagers]

On 24/09/2013 11:07, Frederic Da Vitoria wrote:
> 2013/9/24 Reinier Olislagers <reinierolislagers at gmail.com
> <mailto:reinierolislagers at gmail.com>>
> 
>     On 24/09/2013 09:09, Marco van de Voort wrote:
>     > In our previous episode, Bart said:
>     > Moreover I don't think that first attempts should fixate interfaces
>     > and behaviour forever.
>     It's quite strange though that Delphi compatibility is quite insistently
>     adhered to (BTW a good decision IMO).
>     The function has been in FPC stable (for presumably a while?) so I would
>     really think hard before changing it.
> 
> 
> I could not find any trace of it on the embarcadero web site. Wouldn't
> we be taking into account a compatibility with something which does not
> exist, by any chance?

Ave Frederice ;)

Just to be clear: I'm talking about backward compatibility with FPC
code. I think Bart is, too.
I haven't seen found any Delphi equivalent for the function either.

>     Nice going to show beginning programmers how to break backward
>     compatibility then ;)
> 
> 
> Well, the alternative would be showing how to maintain buggy
> implementations because you don't want to break backward compatibility
> :-) 
Nice one ;)
.. and TBH, breaking implementations is sometimes necesary.
However, see below for why I don't think the returning 0 part is buggy.

> Or it could show that sometimes rules have to be infringed. Or it
> could show the merits of exploring thoroughly the limits of a problem
> before committing code which could later place you in such a conflicting
> situation (I am not throwing stones to the developer who committed this
> function first, I have too often done the same mistake myself)

Remember though that we're talking about choosing between:
If invalid [2] input is found:
1. returning 0 - as the function already does, it's just not documented
as such.
2. raising an exception like a lot of other conversion functions

Keeping in mind that there is no Roman number symbol for zero [1],
option 1 seems quite valid and obvious.

I don't deeply care which choice is made. It's just that I don't think
the additional work and possible impact on changing code outweigh the
benefits. Others obviously disagree, fine ;)

[1] Unless, yes, another exception, you think of Bede's use of N...
[2] Ignoring the discussion about what's invalid as that has little to
doe with the choice mentioned here.