Some months after I uploaded TiltedTorus 2.0a, I looked back on one of its
features in horror.  In order to invoke the Sturmian root solver in
TiltedTorus_Lathe(), I used a global parameter, rather than a macro argument!
If I'd submitted this module as an assignment in one of my computer science
classes, I'd get 20 points deducted just for that.

That's quite a brain fart (though not nearly as bad as having totally unrelated
macro names and function formal parameters override local identifiers).

This is easily fixed, but it would do something that I've never done in an
Object Collection update (save AndroidRobot[1]): break older scenes.

Should I do it?  Older scenes could be quite easily updated, and I don't suppose
many such scenes even exist.  I created this module in response to a request in
p.general, and the OP ended up not using it anyway.

________________________
[1] AndroidRobot's initial incarnation was rather inflexible, and it didn't show
up in the default search anyway, so I figured the benefits to my changes would
outweigh any damage.

Post a reply to this message

On 27-3-2016 4:01, Cousin Ricky wrote:
> Some months after I uploaded TiltedTorus 2.0a, I looked back on one of its
> features in horror.

I think you can safely do it.


-- 
Thomas

Post a reply to this message

Am 27.03.2016 um 04:01 schrieb Cousin Ricky:
> Some months after I uploaded TiltedTorus 2.0a, I looked back on one of its
> features in horror.  In order to invoke the Sturmian root solver in
> TiltedTorus_Lathe(), I used a global parameter, rather than a macro argument!
> If I'd submitted this module as an assignment in one of my computer science
> classes, I'd get 20 points deducted just for that.
...
> This is easily fixed, but it would do something that I've never done in an
> Object Collection update (save AndroidRobot[1]): break older scenes.
> 
> Should I do it?  Older scenes could be quite easily updated, and I don't suppose
> many such scenes even exist.  I created this module in response to a request in
> p.general, and the OP ended up not using it anyway.

Version numbering best practices (such as the "semantic versioning"
scheme) would suggest that you call the new include file "TiltedTorus
3.0" (the major version number increment indicating backward
incompatibilities), and archival best practices would suggest that you
upload it as a new file, rather than replacing the old one. This way,
anyone who for some reason cannot or does not want to change their scene
can still get hold of a compatible include file.

Post a reply to this message

On 2016-03-27 09:49 AM (-4), clipka wrote:
> Version numbering best practices (such as the "semantic versioning"
> scheme) would suggest that you call the new include file "TiltedTorus
> 3.0" (the major version number increment indicating backward
> incompatibilities), and archival best practices would suggest that you
> upload it as a new file, rather than replacing the old one. This way,
> anyone who for some reason cannot or does not want to change their scene
> can still get hold of a compatible include file.

What do you mean by "upload it as a new file, rather than replacing the 
old one" in this context?  New versions of Object Collection modules do 
not erase the old versions, although no guarantee has been made that the 
old versions will remain available in perpetuity.

One way for me to avoid the issue is to use a different name for the new 
lathe macro, and deprecate the old identifiers.

Post a reply to this message

Am 29.03.2016 um 23:18 schrieb Cousin Ricky:
> On 2016-03-27 09:49 AM (-4), clipka wrote:
>> Version numbering best practices (such as the "semantic versioning"
>> scheme) would suggest that you call the new include file "TiltedTorus
>> 3.0" (the major version number increment indicating backward
>> incompatibilities), and archival best practices would suggest that you
>> upload it as a new file, rather than replacing the old one. This way,
>> anyone who for some reason cannot or does not want to change their scene
>> can still get hold of a compatible include file.
> 
> What do you mean by "upload it as a new file, rather than replacing the
> old one" in this context?  New versions of Object Collection modules do
> not erase the old versions, although no guarantee has been made that the
> old versions will remain available in perpetuity.

If old versions are automatically retained, then forget the "archival
best practices" part of what I said. I must confess that I'm not
familiar with the details of the object collection.

> One way for me to avoid the issue is to use a different name for the new
> lathe macro, and deprecate the old identifiers.

I'm not sure if I would do that. But yes, it would be the safest option
in terms of backward compatibility.

Post a reply to this message