|
|
|
[
Permlink
| « Hide
]
Haravikk Mistral added a comment - 13/Apr/07 04:12 PM
Would help if I posted the correct LSL function first time round
Hah, nifty. This sounds like lists in SL behave how arrays in PERL do: if you refer to the list in a "numerical context", you'll get the list's length. I agree this is less than useful for comparing lists. I'd like to see either a fix of the == operator or a llListCompare function. Not only is the function as you show it rather big on code, it's also horribly inefficient: running through two lists like this will be O(n^2).
How List compares work:
!= (not equivalent) return the difference in lengths (a != b is equivalent to llGetListLength(a) - llGetListLength(b)). == (equivalent) return true if the lengths are the same. Fixing this would break existing content in LSL and cause confusion by having != and == working differently. The length comparison quirk is documented on the various wikis. I generally oppose any changes that break existing content and I feel the same about changes that introduce confusion. I cannot in good conscious support this feature request. I kinda agree with Strifes comment. Maybe a new LSL function that did the 'correct' thing would be better than changing the way an existing function works.
On the other hand, if I could vote for an individual comment, I'd cast a ballot for Lex's last one. It is well documented that == compares the length of two lists.
It is reasonable to assume that people have written code which relies on this. Fixing this would break existsing scripts. There is a much simpler function to compare list equality. see http://rpgstats.com/wiki/index.php?title=Annoyances Umm...I counted for this in the bug report. I suggested using === to EXACTLY compare lists. This way people who (IMO wrongly) used == and != to compare lists will not have their content broken, but if you use triple-equals you will get an exact list comparison.
Triple-equals is used in many languages to allow you to compare other return values exactly, such as a comparison between a result of zero and a result of false in many typed languages, so it would make sense to use it for lists as well. Changing to feature request. The current behavior is by design, and therefore not a bug.
integer compare_lists(list a, list b) {
if (llGetListLength(a) == llGetListLength(b)) { if (!llListFindList(a, b)) return TRUE; } return FALSE; } And that was supposed to be list_equals_list. Weee.
And hey, the one on the wiki is better, even.
maybe it would be better to just have a function like llListCompare(list one, list two)?
I agree that making a change that might break functionality is probably not a good idea. Also couldn't it be argued that == should only return true if both names point to the same list (not just lists with the same content)? Changing the behavior or == and != would break existing content. A new list function like llListCompare is the best solution to this problem.
Hmmm... if comparison of 2 lists is comparing the length instead of the list content itself, then the comparison is of the type integer.
So would this make sense? list a = [1]; if (a == b) //so this is type integer comparison because we are comparing the length of the list, right? if (a == 1) //Is this type integer comparison or type list comparison? Are we comparing length of the list or the content of the list? Which type takes precedence? list or integer? You would say list takes precedence because the list a comes first, right? How about this? If you write codes like this, then the code and content needs to be broken. It violates every single programming syntax and type checking. It is absurd to write code like this. Time to fix this when mono comes online. We have to recompile all your code in mono anyways, so why not fix it now once and for all, instead of perpetuating horrible bug that violates any programming language. @Nicoladie: As I recall both Java and C, when using character arrays, if you compare them against each other directly, it just does a pointer comparison and doesn't even look at the values. While LSL's behavior is by all means strange, it is not the strangest and at least it's remotely useful.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||