standardized results for ll functions

Some thing has been bothering me about sls, and I was wondering if I'm not the only one bothered by it.

Right now, llGetListLength returns 0 when list is empty. Mean while llListFindList returns -1 and llList2String( list, 0 ) returns the first item in the list. Almost every programing book, and teacher I have had in programing has stressed the use of a standard. It doesn't matter if -1 or 0 is empty, or if the first item in the list is 0 or 1. Just long as one is chosen.

I'm not saying ll should change llGetListLength, because I don't think I'm the center of the world. And it would probable break hundred if not thousands of scripts. Especially sense it's a simple matter to make a function. But it wouldn't hurt if ll could chose a standard and use that standard for all new functions.

It's not some thing an experienced coder / scripter would get confused about with code their farmilure with, but I wouldn't be surprised if it jinkses a few new scripters and add to the learning curve of the langue.

What would you like? llGetListLength() to return -1 for an empty list? llListFindList() to return 0 when the item is not found? The former doesn't make sense (a list of length -1?) and the latter overloads the case when the item is found in the first (zeroth) position. As it stands, it actually is consistent and makes sense. What I'm saying is that I don't see any inconsistency here at all.

You're talking about two different quantities: the list length and a list item index. Indices start at 0 in LSL lists, like in many languages... it's a pain to get used to if this is your first language, but it really is the way that makes the most sense as you become more experienced with programming (someone famous, I wanna say Dijkstra, had something to say about this, but I can't find it) . If list indices started at 1, perhaps you could make llGetListLength() and llListFindList() return the same thing in their "negative" case, but that would simply be a coincidence. In the end, the list length and a list item's index are two fundamentally different concepts, and the concept of consistency simply doesn't apply.

Trouble is, these (AFAIK) are pretty much standard.
You're comparing different things here:

llGetListLength returning zero is perfectly valid - it's a zero-sized array, which has been legal usage in the various languages I've used that posess the concept. Altering it to return, say, -1, would most likely make things more complex.
llListFindList returning -1 also makes sense, as it's an exception case (this entry wasn't found), and it'd be perfectly possible to find a list entry at index 0, so we need that return value kept free.
llList2String starting from zero index is also valid, as it's standard computing principle in every language from C on up, I think. Arrays start at zero. *shrug* Don't ask me why this is the case, but that's the way it works.

Erm. I've kind of lost the thread here. Nevermind.
Anyway. What I was trying to say (I think), is that we already have these standards (predating LSL, realistically), and they're being held to - you've jost got to remember the designed purpose of each function and you can see why the standard values are the way they are.

yes every thing currently is valid, and makes sense, but it isn't standardized. and yes I agre in the case 0 vs -1. -1 would be more confusing to a novice scripter. But changing llGetListLength to be -1 would be easer then redoing all the other funtions to start a 1 insted of 0.


I am talking about equivalence, under the current system knowing what numtrical value depends on what returned the values.

For all examples bellow assume they should only return true when the values are equivalent not equal.

valueA = 5
valueB = 5

valueA == valueB
valueA + ValueB == 10
valueA / ValueB == 1

if A and B are eqvilent then the above code is correct, and logically true. But if valueB = 5 stands for 6, while a 5 stand for 5. Then the above code is not equivlent, but is still logically true creating a faluse positive.

the only true way of knowing would be to back track through the code till you find out exactly how a and b end up with their values. Usually this requires searching through several functions. Completely ruining the hole point to oop.

But if you knew the statement 0 will stand for 1 to be a constant through out the code. You could read any function logic with out needing to back track through other funtions. Thus perserving the oop of the script.

really i'm just trying to find out if any one else feels the same way I do about this.

No.

As it stands it is both consistent, and makes logical sense.

-Adam

Kurt, you still haven't answered these two very important questions. You're asking for a change, yet do not give specifics on what to change to. Please provide your alternatives to the current functionality, it would help in understanding your argument.
==Chris

The two aren't compairabled.

valid List indexs are from -llGetListLength -> llGetListLength - 1
using llList2<type>list,-1) is the same as passing llList2<type>list,llGetListLength(list))
using llList2<type>list,-llGetListLength(list)) is the same as passing llList2<type>list,0)
so compairing indexs to list indexs to list lengths for inconsistancy is invalid. This example also works with string indexs. Unfortunatly not with llDetected* functions.

Personally, I'd like llGetListLength to return -1 on an empty list. Basically it'd return the number of the last element, rather than the number of elements. Seems to make more sense that way.

The problem with this is that it will break any scripts that use for (i = 0; i < llGetListLength(myList); i++) {}
And it makes more sence for a function named "list length" to return the number of elements composing the list, not the last index.

Oops, missed this:

The universe now makes sence

lol yes it would break many many scripts, just like my original post pointed out. And why it will probable never change.


if llList2String ( myList, 0 ) returns the first item in a list, then 0 represents 1
if 0 represents 1, and llGetListLength ( emptyList ) returns 0, then getListLength has returned 1.
if list size = number of items in list, and there is one item in list, Then list size is one.
if 0 represents one, and there is one item in the list, then one is displayed as 0.

if the character 0 represents numeral value 1 , and numerical value 0 comes right before the numerical value 1, then the character -1 represents the numerical value 0.
if -1 represents 0, and llGetListLength ( emptyList ) returns -1, then llGetList has returned 0.
if the numerical value 0 represents empty, and -1 represents the numerical value 0, then -1 represents empty.

What Christopher Omega said is a red herring. It's true, but it could make people feel like the only reason to keep doing it this way is because people have done it this way in the past. Really, it's done this way because it's the most consistent way.



No. 0 does not mean 1. I see where you're coming from, but about all I can say is that you're just plain wrong. You have to change your thinking around a little to see why, though. We're not using llList2String(myList, 0) because "0 means 1", we're doing this because the first item in a list is the zeroth item. In programming, in almost every language except a very few oddballs, you count like this: "zero, one, two, three..." The first item is the zeroth item. In mathematics this works the same: X0, X1, X2...

Starting from zero rather than one leads to a great many useful results, such as simple looping constructs like the one listed above. It also leads to efficient data representations at the hardware level. This may seem irrelavent to programming consistency, but it's not: in the end, we're telling a computer what to do.

In the end, I can't really help you here, and I can assure you your suggested changes will not be implemented. 0 does not mean one. This is a major hurdle all programmers have to get over: computers start counting at 0, and we have to learn to accept this because it is the only consistent way of structuring a programming language.