Difference between revisions of "Suggested For Deletion/LlSLURL (NewAge)"

From Second Life Wiki
Jump to navigation Jump to search
Line 13: Line 13:
}</lsl>
}</lsl>
:::And yeah, ''that'' would then hardly be justifiable on having it's own page. Though in general, according to [[:Category:LSL Library]], it seems to be welcomed to be put in the main space. --[[File:Zai_signature.png|45px|link=User:Zai Lynch]] <sup><small>([[User talk:Zai Lynch|talk]]|[[Special:Contributions/Zai Lynch|contribs]])</small></sup> 02:58, 4 September 2010 (UTC)
:::And yeah, ''that'' would then hardly be justifiable on having it's own page. Though in general, according to [[:Category:LSL Library]], it seems to be welcomed to be put in the main space. --[[File:Zai_signature.png|45px|link=User:Zai Lynch]] <sup><small>([[User talk:Zai Lynch|talk]]|[[Special:Contributions/Zai Lynch|contribs]])</small></sup> 02:58, 4 September 2010 (UTC)
::::Yeppers. That's basically the same code I suggested on the [[Talk:LlSLURL_(NewAge)|talk page]] but even though the OP did revisit the page after my suggestion no changes were made in favor of the ''better'' code. So since you're the wiki master you'll do the move? I can well imagine I would make a hash of it. Although if we agree that the code stinks and the name is inappropriate maybe simply deleting is better in this case? On a related note and while we're here... I used [[llRound]] instead of typecasting the vector floats. Which would you reckon is the BEST way<lsl>(string)llRound(pos.x)
// OR
(string)((integer)pos.x)</lsl>?
My thinking is that casting float to integer in order to crop the float is basically cheating. I can't help wonder what mess it makes behind the scenes (loads of decimals get cut lose instead of being properly disposed of). Like using integers in vectors (I hate that) E.g. <1, 1, 1> instead of <1.0, 1.0, 1.0>. I'm assuming that since you used tyrpecasting instead of llRound that you think that is the ''better'' way but it is possible you hadn't ever really thought about it (we all after all get into habits). So what do you think? llRound or typecast? Another matter of taste/best-practice.... I tend to use more brackets than many other scriptors (it seems). For example<lsl>return ("secondlife://" + llEscapeURL(region_name) +
        "/" + ((string)((integer)pos.x)) +
        "/" + ((string)((integer)pos.y)) +
        "/" + ((string)((integer)pos.z)));</lsl>Any thoughts? I won't change my ways unless they are inarguably ''bad'' but I would be interested in your views if you care to share them.-- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 04:09, 4 September 2010 (UTC)

Revision as of 21:09, 3 September 2010

Rename the page

Alternative to deletion but, is there a template for that? -- Fred Gandt (talk|contribs) 00:42, 3 September 2010 (UTC)

I think we can just go along and move it. Any suggestions for a new name? :) --Zai signature.png (talk|contribs) 06:01, 3 September 2010 (UTC)
Hi Zai :-) Not knowing what the "NewAge" part is for doesn't help. Calling it simply "SLURL" would be inappropriate I think since that would direct all searches for info on SLURLs. "BuildSlurl" is the sort of name I would give a function that performed this kind of task. But is this really worth its own page? Maybe it is better suited to being featured on the OPs user page? At least then anyone seeking a function for the production of SLURLs will know that this is a user contribution and not the way to do it.-- Fred Gandt (talk|contribs) 14:31, 3 September 2010 (UTC)
Heyas :)
Hm. "BuildSlurl" sounds good to me. The (NewAge) part seems to be something like a brand, since all code snippets posted by the OP got this suffix. So BuildSlurl (NewAge) might be a good spot. I'm not so happy with the code tho. It seems to be more complicated than necessary. Something like this would do the same job and be a bit shorter/simpler:

<lsl>string BuildSlurl(string region_name, vector pos){

   return "secondlife://" + llEscapeURL(region_name) 
           + "/"+ (string)((integer)pos.x) 
           + "/"+ (string)((integer)pos.y) 
           + "/"+ (string)((integer)pos.z);

}</lsl>

And yeah, that would then hardly be justifiable on having it's own page. Though in general, according to Category:LSL Library, it seems to be welcomed to be put in the main space. --Zai signature.png (talk|contribs) 02:58, 4 September 2010 (UTC)
Yeppers. That's basically the same code I suggested on the talk page but even though the OP did revisit the page after my suggestion no changes were made in favor of the better code. So since you're the wiki master you'll do the move? I can well imagine I would make a hash of it. Although if we agree that the code stinks and the name is inappropriate maybe simply deleting is better in this case? On a related note and while we're here... I used llRound instead of typecasting the vector floats. Which would you reckon is the BEST way<lsl>(string)llRound(pos.x)

// OR (string)((integer)pos.x)</lsl>? My thinking is that casting float to integer in order to crop the float is basically cheating. I can't help wonder what mess it makes behind the scenes (loads of decimals get cut lose instead of being properly disposed of). Like using integers in vectors (I hate that) E.g. <1, 1, 1> instead of <1.0, 1.0, 1.0>. I'm assuming that since you used tyrpecasting instead of llRound that you think that is the better way but it is possible you hadn't ever really thought about it (we all after all get into habits). So what do you think? llRound or typecast? Another matter of taste/best-practice.... I tend to use more brackets than many other scriptors (it seems). For example<lsl>return ("secondlife://" + llEscapeURL(region_name) +

       "/" + ((string)((integer)pos.x)) +
       "/" + ((string)((integer)pos.y)) +
       "/" + ((string)((integer)pos.z)));</lsl>Any thoughts? I won't change my ways unless they are inarguably bad but I would be interested in your views if you care to share them.-- Fred Gandt (talk|contribs) 04:09, 4 September 2010 (UTC)