It's clear to me now that making the end offset of each Domain exclusive was a mistake. It leads to situations that are hard to reason about, for instance to draw a strand backwards you have to think about jumping to offsets that are one greater than the one you really want, e.g.,
Note the awkwardness that the two offsets specified, 16 and 11, are not part of the strand at all. These seems less strange when specifying domains by creating explicit Domain objects, but here it's strange that calling draw_strand or cross with an offset, you don't know whether that offset will actually be part of the strand or not, until the next call to move or to that indicates whether the domain will be forward or reverse.
Add a field to Design called end_offsets_inclusive, with default value False, that controls this. If set to True then end offsets will be inclusive.
Some unit tests will need to be added to ensure the new interpretation works.
We can slowly deprecate first by changing the default value to True so that, after we make that change, users will need to explicitly specify a value of False in the Design constructor to make the old behavior appear. If it seems necessary we can eventually remove the field altogether and solely use inclusive offsets.
It's clear to me now that making the
endoffset of eachDomainexclusive was a mistake. It leads to situations that are hard to reason about, for instance to draw a strand backwards you have to think about jumping to offsets that are one greater than the one you really want, e.g.,Creates this design:
Note the awkwardness that the two offsets specified, 16 and 11, are not part of the strand at all. These seems less strange when specifying domains by creating explicit
Domainobjects, but here it's strange that callingdraw_strandorcrosswith an offset, you don't know whether that offset will actually be part of the strand or not, until the next call tomoveortothat indicates whether the domain will be forward or reverse.Add a field to
Designcalledend_offsets_inclusive, with default valueFalse, that controls this. If set toTruethen end offsets will be inclusive.Some unit tests will need to be added to ensure the new interpretation works.
We can slowly deprecate first by changing the default value to
Trueso that, after we make that change, users will need to explicitly specify a value ofFalsein theDesignconstructor to make the old behavior appear. If it seems necessary we can eventually remove the field altogether and solely use inclusive offsets.