Hi, sorry for adding more noice. My message concerns the "meta" side of the discussion, i.e. whether to preserve functional compatibility or the original name. This is a central issue in Liitin ( http://liitin.finndesign.fi ), so I've given a lot of thought about it, but this topic/noise served as an excellent opportunity to study this aspect even deeper. Thanks everyone contributing!
The thinking process was extremely fruitful, so I thought I'd better document it somehow, and maybe sharing it could benefit others as well, regardless whether agreeing or disagreeing with it. These thoughts are mainly common-sense reasoning and usability related, and Liitin centered in places. ( http://en.wikipedia.org/wiki/Law_of_the_instrument :) I'm likely to be wrong in many places so please correct me. Thoughts so far: I've often found it very useful method to exaggerate things when trying to extract the essence out of too vague or too close situations. In this subject, rather than thinking about a few people needing to update near-history programs, think about a million people needing to update a hundred years old programs. The referred code, again has been changed 1000 times during the hundred years. Which approach feels more comfortable and enduring; keeping the old name, but changing it whenever some other approach feels better, or stick to strict compatibility and occasionally create renamed variants, if it would break compatibility otherwise (e.g. change the order of arguments, add remove arguments, change the format of arguments...)? Both are inconveniences, but in a different ways. However, adding new variants and finding them seems to stay as an inconvenience, whereas braking the compatibility soon escallate problems until unmanageable. Side note: Any improvements (such as little tweaks, optimisation, bug fixes, total rewrite) no matter how small or grand, fall into category 'update' as long as there are no changes in the interface that would break the compatibility. Of course, these are just recommendations which anybody could either follow or not. The good thing with Liitin, however, is that even in cases that the recommendations are not followed (the interface changes under a single name), you can easily deal with it by simply ignoring dynamic changes ('latest') and use timestamped versions instead. E.g. (function-x arg1 arg2 arg3) > (function-x arg3 arg1 arg5) >> (function-x:timestamp-a arg1 arg2 arg3) (function-x:timestamp-b arg3 arg1 arg5). Eventhough still inconvenience, it is way smaller than needing to change your or somebody else's code(s). And on the next abstration level it doesn't really matter; it's already hidden. Or, you could use your own namespace to give new names to objects, yet referring to other's code, either timestamped or allowing dynamic, future updates from the original author. Keeping the name as well as the interface as intuitive and practical as possible is very important, so I'd rather see evolutionary variants as needed, rather than strictly stick to the originals (say, car & cdr). Eventually, best practices will settle down. None ot the code versions (within the same name) or variants (similar functions under different names) are ever lost in Liitin, but there's a need for especially good search mechanisms. Experimentation should by no means be limited by these measures, on the contrary. Codes and names should evolve, but being ably to safely harness both wider and time-wise deeper range of others' work, will allow much greater level of abstraction to experiment with. To apply this to case 'Plot': If the compatibility cannot be preserved, pick a new name for the new variant (intuitive for a new-comer rather than resembling the old one), and be especially careful not to break compatibility with the existing code base (retrospectively). And of course, inform about the existence of the new variant. Now it is easy to see the pointers in the discussions, but in the beginning it was quite blurry. To me, at least. br, jukka | J U K K A T U O M I N E N | m a n a g i n g d i r e c t o r M. A. | | Finndesign Kauppiaankatu 13, FI-00160 Helsinki, Finland | mobile +358 50 5666290 jukka.tuomi...@finndesign.fi | www.finndesign.fi _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
