Difference between revisions of "Talk:LlHTTPResponse"
Jump to navigation
Jump to search
Void Singer (talk | contribs) m (Resetting (recte: clearing) The query string?) |
|||
Line 2: | Line 2: | ||
ok, I'll bite.... why would you need to do this? I get the freeing up the memory taken by a key, buy you shouldn't be checking the the uuid anyways, but rather what the method was used, to determine what to do with the data. if anything you should be tracking the uuid returned in case you aren't returning a response in the llHTTPResponse event (and if you are, there's no need to track it outside the event)<br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 00:46, 10 October 2012 (PDT) | ok, I'll bite.... why would you need to do this? I get the freeing up the memory taken by a key, buy you shouldn't be checking the the uuid anyways, but rather what the method was used, to determine what to do with the data. if anything you should be tracking the uuid returned in case you aren't returning a response in the llHTTPResponse event (and if you are, there's no need to track it outside the event)<br/>-- '''[[User:Void_Singer|Void]]''' <sup><small>([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]])</small></sup> 00:46, 10 October 2012 (PDT) | ||
:I dunno what the editor's exact reason(s) are, but I think it's always good practice to reset any key you're no longer using as there is that tiny, tiny chance of the same key being used again. I do agree though that the method should really be checked first, as in theory there could be a future method that won't have a key (e.g - some kind of information event that is triggered automatically, rather than being requested), in which case the example would try to send a reply that may not have a destination, aside from that it's good practice to restrict behaviour to only the method(s) you expect to receive. Also, I personally think it's generally good practice to reset keys to [[NULL_KEY]] rather than an empty string; I know that for a single value it doesn't matter much but if you use a lot of keys then they can add up, and you should really keep the memory "reserved" so you're not using memory that you think is free, unless you know the variable is never going to be used again, but in that case you should be trying to eliminate it =) <br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 02:13, 10 October 2012 (PDT) |
Revision as of 01:13, 10 October 2012
Resetting (recte: clearing) The query string?
ok, I'll bite.... why would you need to do this? I get the freeing up the memory taken by a key, buy you shouldn't be checking the the uuid anyways, but rather what the method was used, to determine what to do with the data. if anything you should be tracking the uuid returned in case you aren't returning a response in the llHTTPResponse event (and if you are, there's no need to track it outside the event)
-- Void (talk|contribs) 00:46, 10 October 2012 (PDT)
- I dunno what the editor's exact reason(s) are, but I think it's always good practice to reset any key you're no longer using as there is that tiny, tiny chance of the same key being used again. I do agree though that the method should really be checked first, as in theory there could be a future method that won't have a key (e.g - some kind of information event that is triggered automatically, rather than being requested), in which case the example would try to send a reply that may not have a destination, aside from that it's good practice to restrict behaviour to only the method(s) you expect to receive. Also, I personally think it's generally good practice to reset keys to NULL_KEY rather than an empty string; I know that for a single value it doesn't matter much but if you use a lot of keys then they can add up, and you should really keep the memory "reserved" so you're not using memory that you think is free, unless you know the variable is never going to be used again, but in that case you should be trying to eliminate it =)
-- Haravikk (talk|contribs) 02:13, 10 October 2012 (PDT)