On 07/28/2015 10:57 AM, Fabien COELHO wrote:
>
>> AFAICS, that isn't exactly an improvement. You're telling the user
>> "if you have an ISBN column, you're screwed, and we are going to make it
>> as painful as it can possibly be to get out of that situation".
>>
>> I think we'd be better off trying to migrate to a situation where these
>> type names all still exist but they all act like ISBN13. I'm not sure
>> what the stages on that journey are.
>
> Hmm... This is more or less what the previous version was doing, including
> display bugs.
>
> So the attached v3:
> - distinguishes internally between ISBN & ISBN13 (so it is clean),
> but accepts values of one for the other transparently.
> - displays ISBN as ISBN if possible, otherwise they are show as
> ISBN13. This fixes the reported bug, and the application would
> have to adapt.
> - adds regression tests, including expected errors.
>
> The good news is that there is no extension version update, it is just a
> behavioral change when ISBN13 numbers are used with the ISBN type.
Hmm, I don't think we need or want the separate ISBN and ISBN13 codes
internally. They're used interchangeably, anyway. If we just apply your
change to ean2ISBN(), we're done. Per the attached.
Thanks for the regression tests, that was very badly needed!
- Heikki
