Jump to content

Reverse Reprised


PeterCanessa Oh
 Share

You are about to reply to a thread that has been inactive for 4452 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

In a lazy sort of way I'm collecting a library of utility routines.  The wiki includes string-reversal functions http://wiki.secondlife.com/wiki/StringReverse but I think the one below is slightly better.  Comments, improvements?

 

string StringReverse(string Input){
	// Reverses a string
	integer Counter = llStringLength(Input);
	while(Counter--){
		Input = llDeleteSubString(Input, Counter, Counter) + llGetSubString(Input, Counter, Counter);
	}
	return Input;
}

 

Link to comment
Share on other sites

It's a nice exercise butI don't really know why anyone would want to reverse a string. The LSL supports indexing for reading backward as well as forward so the only implementation I see is for inter-object communications security but simply reversing is a very poor security.

As for the code, yours has the same problem as those in the wiki, you double (or maybe even tripple) the memory required to hold the string so for large strings I wouldn't recommend any user function but doing in-line.

Link to comment
Share on other sites

To be honest I can't think of a good reason for reversing a string either, but it could just happen someone wants to be able to type some text and have their titler show it backwards, who can tell.  Several months ago we had a request from someone who wanted to reverse all the numbers in a string - no idea why, but if the desire's there we can meet it :-)

Now I have to admit to a very bad reason why I looked in the first place - having posted a postfix expression-calculator recently (http://community.secondlife.com/t5/LSL-Library/A-better-postfix-evaluator/m-p/1338283#M421) I wanted to find the simplest way to also support prefix.  First thought was to run through the parsed list backwards (which would work) but there were a few too many changes to the handling of 'pointer' for me to bother.  Then I thought that all I had to do was reverse prefix and I'd get postfix, so I looked at string-reversal.  The trouble with that, of course, is that it also swaps the order of the operands, so *blush* I was just being stupid.  Ah well, so much for shortcuts.

[For those that like their gibberish but are new to this:

  • / 1 2 (prefix) is the same as 1/2 (infix, the normal way of writing equations)
  • In postfix the same thing is written 1 2 /
  • But just reversing / 1 2 (prefix) gives 2 1 / (postfix), which is 2/1 (infix), so wrong result 2, instead of 0.5]
Link to comment
Share on other sites


Ela Talaj wrote:

[...]

As for the code, yours has the same problem as those in the wiki, you double (or maybe even tripple) the memory required to hold the string so for large strings I wouldn't recommend any user function but doing in-line.

That's a good observation, Ela.  It raises a more general thought in my mind.  Code snippets are often presented here and in the LSL wiki as user defined functions, possibly because that's a handy way to make it clear what sort of input they require.  I suspect that many (most?) scripters simply pull out those functions and pop them into a script as is, when it would be wiser to inline the code instead.  I'm thinking, in particular, of snippets like PosJump that typicaly need to be called once in a script.  There's usually no reason to use something like that as a global function.  (Yes, I know PosJump is about to be eclipsed by llSetRegionPos, but the example is a familiar one. In fact, llSetRegionPos is a decent illustration of a function that will be much more efficient than its UDF equivalent, in part because it is inlined.)  We've had this discussion here before, but my personal rule -- not a "one size fits all" but close -- is to define a UDF only when I will need to call the same bit of code from more than two or three places in a script.

Link to comment
Share on other sites


Rolig Loon wrote:

...Code snippets are often presented here and in the LSL wiki as user defined functions, possibly because that's a handy way to make it clear what sort of input they require...


 

Yeees, but I think it's usually because these routines are self-contained.  You don't have to know how or why they work; just that given the parameters stated they'll work without any side-effects on the rest of your script.  Parameters are pass-by-value, local variables' scope is limited to the function.  That means you don't have to worry about things with the same name but different type causing and error or of the same type being changed without you realising.  The self-contained, encapsulated, fire-and-forget, (as you said yesterday) 'black box' has a lot going for it, if you overlook pure efficiency.

Hehe, apart from anything else, having a single, easily-identified, function makes it easier to copy and paste.  Those that know how and can will inline the functionality if they want to.  Those that don't/can't don't need to.  Easy.

Link to comment
Share on other sites

Yeah, good point, Peter.  Black boxes are useful.  I'm just saying that a smart scripter (you?  me?  Ela?) probably wouldn't just grab a function like that and pop it into a script without (a) knowing what it was doing and (b) asking whether it might be smarter to inline the code instead.  I guess that means that I'd prefer to hope that the average scripter doesn't think of a bit of code here or in the wiki as a black box.   It's a faint hope, perhaps, but that's what was in my mind.

Link to comment
Share on other sites

Oh yeah, don't get me wrong, you and Ela have good points, it's just that my priority is always clarity and ease of maintenance before efficiency.  To put it another way; make it do the right things before doing things right.  As you said, we have had conversations about when to separate-out functionality and other aspects of coding-style - and there are no solid rules.  Part of the fun is learning how you prefer to juggle the various resources available to a script (such as memory vs time vs clarity) in order to achieve your goals.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4452 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...