Difference between revisions of "Talk:Separate Words"
(New page: This is going to return the wrong answer when there are inclusive or total collisions between separators and spacers. -- ~~~~) |
(suggest a project: experiment, specification, design, implementation, documentation) |
||
| Line 1: | Line 1: | ||
This is going to return the wrong answer when there are inclusive or total collisions between separators and spacers. -- [[User:Strife Onizuka|Strife Onizuka]] 09:32, 12 September 2007 (PDT) | This is going to return the wrong answer when there are inclusive or total collisions between separators and spacers. -- [[User:Strife Onizuka|Strife Onizuka]] 09:32, 12 September 2007 (PDT) | ||
Thought-provoking, thank you, I've responded inline below. -- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 05:11, 13 September 2007 (PDT) | |||
'''Context''' | |||
We mean to be discussing the astonishing test case of including the same string in both the separators list of strings to keep and yet contradictorily also in the spacers list of strings to discard. | |||
'''Experiment''' | |||
We should experiment with this test case, sampling how llParseString2List responds to that this case in world in Second Life. | |||
'''Specification''' | |||
We have no specification for this test case. | |||
Our only sources for specification come up empty: | |||
A.175. llParseString2List of the 2007-08-01 "Linden Scripting Language Guide.html" does not discuss this test case. | |||
The [[llParseString2List]] article of this LSL wiki does not discuss this test case. | |||
'''Design''' | |||
We should have designed the llParseString2List function to avoid astonishing the programmer, in this test case as with any test case. | |||
Least astonishing might be for any string found in both lists to have no effect, or have the effect of a spacer, or have the effect of a separator. | |||
We should specify the effect of a spacer, because people testing code are more likely to notice the keep effect of a spacer, rather than the discard effect of a separator, or the null effect you get when you omit a string from both lists. | |||
'''Implementation''' | |||
Maybe we should tweak the separateWords example to complain, via llOwnerSay, any time the programmer does violate this precondition. | |||
Maybe we should tweak the separateWords example to produce the effect of spacer when the same string appears in both lists. | |||
Maybe we should add examples to show concretely how dramatically simpler and shorter the code becomes when there 0 separators together with more than 8 spacers, or 0 spacers together with more than 8 separators. | |||
'''Documentation''' | |||
We should edit the [[llParseString2List]] and [[Separate Words]] articles to remind the programmer to work to avoid violating this precondition. | |||
Our English might be: Every string of the '''{{LSL Param|spacers}}''' to keep must not exist in the '''{{LSL Param|separators}}''' list of strings to discard, to avoid contradiction. | |||
We should edit these articles to caution further, when we're doc'ing code that does not to produce the effect of a spacer for a string that is both separator and spacer. | |||
Revision as of 04:11, 13 September 2007
This is going to return the wrong answer when there are inclusive or total collisions between separators and spacers. -- Strife Onizuka 09:32, 12 September 2007 (PDT)
Thought-provoking, thank you, I've responded inline below. -- Ppaatt Lynagh 05:11, 13 September 2007 (PDT)
Context
We mean to be discussing the astonishing test case of including the same string in both the separators list of strings to keep and yet contradictorily also in the spacers list of strings to discard.
Experiment
We should experiment with this test case, sampling how llParseString2List responds to that this case in world in Second Life.
Specification
We have no specification for this test case.
Our only sources for specification come up empty:
A.175. llParseString2List of the 2007-08-01 "Linden Scripting Language Guide.html" does not discuss this test case.
The llParseString2List article of this LSL wiki does not discuss this test case.
Design
We should have designed the llParseString2List function to avoid astonishing the programmer, in this test case as with any test case.
Least astonishing might be for any string found in both lists to have no effect, or have the effect of a spacer, or have the effect of a separator.
We should specify the effect of a spacer, because people testing code are more likely to notice the keep effect of a spacer, rather than the discard effect of a separator, or the null effect you get when you omit a string from both lists.
Implementation
Maybe we should tweak the separateWords example to complain, via llOwnerSay, any time the programmer does violate this precondition.
Maybe we should tweak the separateWords example to produce the effect of spacer when the same string appears in both lists.
Maybe we should add examples to show concretely how dramatically simpler and shorter the code becomes when there 0 separators together with more than 8 spacers, or 0 spacers together with more than 8 separators.
Documentation
We should edit the llParseString2List and Separate Words articles to remind the programmer to work to avoid violating this precondition.
Our English might be: Every string of the spacers to keep must not exist in the separators list of strings to discard, to avoid contradiction.
We should edit these articles to caution further, when we're doc'ing code that does not to produce the effect of a spacer for a string that is both separator and spacer.