Difference between revisions of "Talk:LlList2CSV"
| Line 6: | Line 6: | ||
[[User:Chaz Longstaff|Chaz Longstaff]] 17:36, 14 July 2008 (PDT) | [[User:Chaz Longstaff|Chaz Longstaff]] 17:36, 14 July 2008 (PDT) | ||
:With functions like llSortList and llDeleteSubString a user coming from a language that does not have immutable lists and strings (very common) will have the expectation that these functions mutate the src parameter. But this expectation of mutation only exists for the purest of functions and to counter balance this is the expectation that the parameters won't be needlessly trashed by function calls. If llList2CSV were to mutate the src from a list into a string it would be trashing the parameter. Then there is the issue that LSL is strongly typed, there is no support for changing a variable type once it is declared (typecasts change the value after it has been copied from a variable, it doesn't actually do anything to the variable). Having this as a caveat gives the suggestion that LSL is not strongly typed. | |||
:The template would just insert the text automatically into the caveats section. The advantage of this being that the text would be consistent across all articles. | |||
:Really the immutability of lists and strings shouldn't be repeated on these pages but should be in the tutorials, type articles, and in a language specification about LSL. It's a universal rule of LSL that functions cannot modify the variables that provided the values for their parameters; we shouldn't be restating it everywhere. -- [[User:Strife Onizuka|Strife Onizuka]] 19:16, 14 July 2008 (PDT) | |||
Revision as of 19:16, 14 July 2008
>> Strife says: This function transforms the data, there is no expectation of modification, so the caveat isn't needed, though it is on other string and list function articles. I've been meaning to make a template.)
I would propose that for learners, who can make this mistake as I did many times when exhausted in the battle to learn LSL, that a caveat is useful, and that it does no harm for those who don't need it, as they can just ignore it? Part of my aim is to make the advice / language accessible to learners. As well, as you point out, it would be inconsistent not to have it here, as it is other similar places?
I like your idea of templating it, perhaps to appear as a definite Caveat that stands out, rather than something in a footnote?
Chaz Longstaff 17:36, 14 July 2008 (PDT)
- With functions like llSortList and llDeleteSubString a user coming from a language that does not have immutable lists and strings (very common) will have the expectation that these functions mutate the src parameter. But this expectation of mutation only exists for the purest of functions and to counter balance this is the expectation that the parameters won't be needlessly trashed by function calls. If llList2CSV were to mutate the src from a list into a string it would be trashing the parameter. Then there is the issue that LSL is strongly typed, there is no support for changing a variable type once it is declared (typecasts change the value after it has been copied from a variable, it doesn't actually do anything to the variable). Having this as a caveat gives the suggestion that LSL is not strongly typed.
- The template would just insert the text automatically into the caveats section. The advantage of this being that the text would be consistent across all articles.
- Really the immutability of lists and strings shouldn't be repeated on these pages but should be in the tutorials, type articles, and in a language specification about LSL. It's a universal rule of LSL that functions cannot modify the variables that provided the values for their parameters; we shouldn't be restating it everywhere. -- Strife Onizuka 19:16, 14 July 2008 (PDT)