Allow ll.LinksetDataRead to return nil when the key pair does not exist in the data store.
tracked
Anna Salyx
ll.LinksetDataRead("key") and ll.LinksetDataReadProtected("key", "pass") both will return an empty string if trying to access a stored value that doesn't exist. Which is not "nil".
Can we get it so that if a key pair does not exist in the LSD store that the return is actually a "nil" type instead? It would also return nil on a protected key with a bad "pass".
We have access to the nil data type with SLua now, and it'd be more logical for a non-existent key to return nil for a simple boolean test. IMO. Just an idea at least.
Added thought:
maybe have "llcompat" have the return still be a zero length ("") string for, well, compatibility sake.
Log In
H
Harold Linden
marked this post as
tracked
Thanks for the suggestion! I'll bring this up at the next user group meeting to see if there's consensus.
H
Harold Linden
Interesting, I'll have to think about the API implications.
Are there any other obvious functions that return "" as a sentinel value when it'd be more sensible to return
nil
? Maybe the notecard stuff that returns NAK
should logically return nil
, or would that be weird given that it has other sentinels like EOF
?Nexii Malthus
Harold Linden Hmmm,
- llGetInventoryNamereturns empty string if not found this could returnnil
- llGetInventoryDesccan return empty string if item has no description but think that makes sense to have as an empty string because that's what it is. Same withllGetObjectDesc.
- llGetDisplayNamecan return an empty string in certain conditions, but also has other weird return values possible ("???"/"Loading..."). Honestly this is really messy and needs to be really fixed / unified. Just returningnilon: empty strings,"???"and"Loading..."
- llGetUsernamelikewise can return""if unable to resolve, should returnnilinstead
- llKey2Namereturns an empty string for non-existent avatars/prims, this is often used as a useful presence check in a lot of scripts, could returnnilfor same usage
- llGetRenderMaterialreturns... a name, uuid or null key? Returning either string name, native uuid ornilwould be fine here
- llGetParcelMusicURLcan return an empty string, but not familiar with the function, guess it could returnnilif not set or failing the permission?
- llGetNotecardLineSyncis a bit complex yeah since it can returnNAKorEOFwhich are not comparable tonil
Anna Salyx
Harold Linden I'm not sure about ll.GetNoteCardLineSync. The NAK is specifically for cases when the notecard data has fallen out of the regeion cache.
A dataserver function to get the number of notecard lines and to get a notecard line Asynchronously loads the notecard data into the region cache which can then be retrieve by the synchronous method thereafter. But if that notecard data expires or is pushed off the stack, then a NAK is returned to say "hey, that's not currently available, try the other way." So, I'm not sure "nil" if wouldn't fulfill the same purpose. NAK just might be a functional synonym of nil. Unlike EOF which says "no more data", NAK or nil both could say "data not currently available".
Not that all said.... My own personal preference would be to keep NAK in this case since it mentally/naturally goes hand in hand with EOF for notecard reading: Line not available / No more data
Oh! And a zero length line should always return a zero length line of course.