In topic
http://forum.blackboxframework.org/view ... =265#p2361 Berhard wrote
Bobs last post (3. Feb. 2015) contained:
"I have also now discovered two new bugs, which have always been there."
I guess/hope that Bob's Version above includes these "unpublished" changes, but I don't know.
In fact that version was published here on 13-Feb-2015 in topic
http://forum.blackboxframework.org/view ... =186#p1886. This is exactly the same version as I recently published in topic
http://forum.blackboxframework.org/view ... =265#p2365.
These versions differ from the Zinn / CPC version being discussed here with regard to what Chris calls "Forward compatibility", the topic of the second link above. This topic never reached an agreed decision.
I would like to reopen this topic here as I think that the "benefits" of
partial forward compatibility do not justify the additional complexity, and in fact have some disadvantages. (Both versions do provide full "Back" compatibility; that is not being questioned.)
I was intending to open this compatibility discussion after any modifications and improvements to the current proposal had been agreed. But as I will be out of contact for the next three weeks I decided to open it before this thread is closed.
The argument is: If we write a Stamp in BlackBox 1.7, must it be
fully functional in BlackBox 1.6? If so, then we cannot provide for 16-bit characters in Stamps. But we have already decided to do that, so
full forward compatibility is a lost cause.
All versions provide a high level of forward compatibility. The Document is readable / editable /saveable in BlackBox 1.6, except that the Stamp itself is unavailable (it is an Alien). When the Document is reopened in BlackBox 1.7 the Stamp comes back to life. This represents a very small level of inconvenience, as people who write / develop on 1.7 will only occasionally and briefly have reason to refer to version 1.6. Stamps are mainly used by their authors, I can't imagine someone publishing Documents from 1.7 where a wide audience of 1.6 users need to open the Stamps.
The CPC version includes the additional logic to save a Stamp that only contains 8-bit characters in BlackBox 1.6 format. This provides some small additional level of forward compatibility. It comes at the cost of extra code complexity.
However I see two problems. We now have two classes of users; People who's native alphabet is 8-bit who have an "advantage" over people who's alphabet is 16-bit. I think this division is undesirable.
Even people (myself!) who appear to live in the 8-bit world do frequently use other unicode characters. I might write "Changed this → that", or I might use a Greek symbol to describe an equation. Even if most of my comments are only 8-bit, it only takes 1 non 8-bit character to loose my forward compatibility "advantage". I might be deterred to write the comment I want in order to keep my "advantage".
Better, and simpler, to make the change to 16-bit completely.
I do have another point, which I shall not discuss in detail here. If we accept that 1.7 Stamps are not
fully forward compatible to BlackBox 1.6 we have the option to change the number of comments from 25 (at present) to 35, or another number, or a variable number. If this is considered to be too much of a
feature to be considered just now, I will still argue to make the code capable of supporting a variable number (it involves writing 1 extra number to disc) so that if we subsequently (BlackBox 1.8 ?) do agree to change the number of comments we can without breaking back or forward compatibility from 1.7.