On 24/09/2013 11:07, Frederic Da Vitoria wrote: > 2013/9/24 Reinier Olislagers <reinierolislag...@gmail.com > <mailto:reinierolislag...@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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal