Function overriding

I have a question about function overriding, as that is the only thing I can think to call it.

In some languages, like PHP, you can do the following code:

test()
{
// do something here
}

test2()
{
//do something else here
}

main()
{

$temp = "test";

temp();

$temp = "test2";

temp();

}

which will first call the function test, and then call the function test2. I am wondering if there is similar functionality in Second Life. I am not able to check in SL at the moment to test this for myself. Any help would be appreciated.

There isn't.

Though, you could potentially do some complex things using linked messages to other prims, and change the prim links or something to give it the appearance of a variable function dispatch.

But that doesn't seem too practical for most applications.

Thanks, I didn't think I'd be lucky enough to find that type of functionality in Second Life, but never hurts to ask at least.

Its just function look up , nothing more complex than that. You can do exactly the same thing with LSL using if/else if or a list look up calling a function based on the result.

Like this:

temp(integer switch) {
if (switch == 1) // do number 1
else if (switch == 2) // do number 2
}

main() {
temp(1);
temp(2);
}


or this:

integer switch;

test1() {
//do number 1
}
test2() {
//do number 2
}

main() {
if (switch == 1) test1();
else if (switch == 2) test2();
}

Yeah you can of course dispatch with if statments.

I think the posters comment was toward functionality, in some other languages, which does a more "pure" indirect call.

I ended up just using if statements. The list itself is a bit long tho, so I have a bunch of them. I would have much rather just been able to dole it out based on a string than a bunch of extra if statements. Oh well, maybe one day LL will allow us to do this.

Thats just pushing the look up behind the scenes and promoting lazy programming.

Don't be silly. If-else tables become extremely unwieldy very quickly, especially when the lookup table is subject to dynamic changes. Depending on those dynamic changes, it can actually become quite impossible for if-else to do the job, but sure, no matter what, you can achieve the same effort with more coding. Heck, all we need is one numeric type and some half dozen instructions (xor, and, not, a conditional branch, store value, retrieve value) and we're Turing Complete! We can do anything that -any- programming language can do! Writing in anything more complex than this minimal assembly language instruction set is clearly just lazy programming...


Sarcasm aside, intelligent laziness* is a virtue in programming. Writing something in a way that takes more time and more statements just because you can is -not- a virtue. Writing something simpler, more readably, using less statements is a virtue. Yes, there are other tradeoffs involved too, but writing complicated nests of arrays referencing arrays and if-else tables when a simpler structure would make a clear, short program ... there's a clear win here.


*(Yes, the laziness is a virtue bit is a lot like stuff Larry Wall has said.)

Laziness is never a virtue. Especially in programming.

You've missed my point but thats not unusual. My back ground is hard real time and safety critical systems so I tend to look at things differently from a lot of people.
I am all in favour of efficiency and streamlined code but not at the expense of 'safety'.
The 'variable becomes a function' idea posted above allows what i consider to be a very dangerous practise. You are basically saying "hey I can't be bothered to validate my own input so you can do it." to the compiler. Thats all very well and good as long as it make sense but with no try-catch/exception handling mechanism to safe guard it its just a disaster waiting to happen.

Yes huge if/else trees are ugly, unweildy and to be avoided, but if you do have to use em at least you know why and how.

Oh and I do still program in assembler when I have too and spent several years directly inputting octal byte codes via piano keys....

Perhaps demonstrating a flair for the obvious:

There's a difference between overloading and function pointers--the latter of which need not be just syntactic sugar for branched dispatching, and can have significant performance advantages (and substantial risk of hard-to-debug error conditions).

I have to agree with Newgy there; laziness is DEFINITELY NOT a virtue when it comes to programming. Finding simple, elegant, clean solutions to a problem in code requires more effort in the vast majority of cases.

Programming is a LOT like math (well, yah, "algorithms", duh ). You spend a lot of time writing out equations, sometimes really long ones, in the process of combining and deriving others. During that process, you simplify them by removing terms which cancel each other, and combine operations to simplify down to the resultant equation, going from significant complexity to something elegantly simple. That process is a lot of work, but it HAS to be done to get a "correct" equation at the end. What generally happens when writing a program is that the "lazy" programmer starts out with the problem and "infers" the solution from it, taking obvious "shortcuts" in his logic, or using the logic of the programming tools he is using, without going through the intervening derivation steps to really understand it. As a result, you see something which kinda works, except in circumstances which aren't tested, but are valid real-world cases, and you have absolute crap as a result.

After writing my own software and working on others' for 30 years now, I find I agree with Sturgeon's Law:

90% of everything is crap.

..and Coletti's Corollary to Sturgeon's Law:

Sturgeon's Law is recursive.

Hard real-time systems that control physical devices are an entirely different case, and require disciplines that are not really relevant in pure software. In pure software, if you can write code that works 99.9% of the time in 1 hour or code that works 99.999% of the time in 1 week, you take the hour coding option.

In any hard real time system, you do the reverse. In a hard real time system that can have life-threatening consequences, you do the reverse and then you build a failsafe that catches 99.999% of those 0.001% of the time cases... (Well, actually, many apparently don't, see risks digest, but they should.)

Anyway, 'Laziness is a virtue' means that it's better to write something so that it is reusable and you won't have to do it twice, it is better to use a high level function than to re-invent the wheel. You can laugh at the notion all you like, but for people in the scripting language communities (meaning perl, python, php, &c) it makes all kinds of sense.

As for how function references of various types validate their arguments, that's very dependent on the implementation. In C, a function pointer is a deadly thing if misused and any table of function pointers simply must follow a strict calling convention. In perl, everything is so weakly typed that you can just pass anything to anything, and in general you write your functions knowing that. In the smarter-compilers object oriented languages (python, java, &c.) you'll get strict argument checking even though your function (or, actually, method) is abstracted.

Call it ridiculous and absurd and whatever, but if it wasn't seen as useful by a lot of programmers there wouldn't be such mechanisms in most high level languages. (Even C with function pointers!) Trying to dismiss as a bad idea on its face something that appears in language after language makes no sense to me. Trying to apply safety-critical hard real-time practices to action scripts within a video game makes no sense to me.

Sloppy thinking and unverified shortcuts in writing your code is stupid and uncreative laziness. The intelligently lazy would never do that, because they know it will make MORE work later when they have to maintain the buggy code. No, it is much nicer and easier to write it once, correctly. Much less effort in the long run! Similarly, the intelligently lazy know that commenting NOW will save pain and frustration LATER. The foolishly lazy think commenting is unnecessary...

Something else in there I don't know that I understand. Are you saying you shouldn't trust the logic and correctness of a toolkit that you're using? If that's the case, then you might as well not use any third-party toolkits ever. Of course, because you are trusting them to be correct, you want to be sure you are using stable tools. You might do some testing of your own just to be sure, but mostly you must rely on other people's experiences.

Since we're talking about math: we all use Leibniz's notation for Calculus because it's just simpler than Newton's, even though they're equivalent. So that's "lazy"--in much the same way that functional polymorphism in OOP is "lazier" notation. But that laziness can make it *easier* to spot (some) errors, too, when the code is simpler to read.

Perhaps you are coining new phrases, then. The word "lazy" means "aversed to work" or "slow"; in programming terms, that means not doing due diligence, not verifying code paths, not documenting, not THINKING things through, etc. I am not sure what "intelligence" has to do with being "lazy" when writing code. To me, it says you "you know better", but you don't follow through. Being creative and finding creative solutions to problems is anathematic to "laziness", because it most often takes effort to come up with such things ("Genius is 1% inspiration, 99% perspiration" -- T. Edison).



I don't trust anything I didn't write 100%, and sometimes I don't even trust what I wrote, but I trust it more than what someone else did, because I *can* KNOW it is correct, and I can prove it so. I've been bitten by far more than my fair share of buggy compilers, buggy library functions (llXorBase64Strings, anyone?), and broken platforms. I use them, but I never fully trust them if I didn't write them. As such, I make sure that what *I* write isn't the weakest link in the chain. I *ALWAYS* do things like using parentheses to explicitly state to the compiler (and to anyone reading the code down the road, including myself) the order of evaluation. "Lazy" programmers always laugh and scoff at it, until they get bitten by a borked language that doesn't obey its own operator precedence rules (and, oh boy, the OUTRAGE that ensues then! Welcome to the club, junior...).



I have to stringently disagree with that notion. "Pure software" or not is irrelevant to the issue of programmer laziness. Would you like your bank to use that kind of logic when processing your account transactions? Yeah, it has to do with "mission criticality", but if putting in two hours of work takes you to 99.9999999% (or 100%, if you can apply software proofing methods to the code in question), it is worth the extra hour, IMO. Most often, "lazy programmers" take the hour and don't see any value in spending even one more hour to be "sure". That's why we have crap software, because they didn't take a reasonable amount of extra time or attention to their code to make it better.



Yep, I definitely think you are coining your own phrases there. Writing reusable code usually takes more initial effort, which is, again, not being "lazy". Is it better to use a "high-level function" than to re-invent the wheel? If I find I can trust the "high-level function" enough, then maybe. Most of the time, I find that I can; I just make damn sure that any goofyness I can imagine occurring on the part of that function is considered and accounted for.



Things that appear in language after language are often there because of popularity and perceived utility, not because they are necessarily "safe", nor the best way to do any particular thing. Some "tools" in any particular language's toolbox are like circular saws without blade housings and guards. You BETTER know what you are doing when you use them, avoiding "laziness", or you're going to get seriously messed up. I've had to clean up enough "lazy programmer" code where such things are badly misused, that I'm a fan of better mechanisms in a language which encourage good programming habits, rather than bad ones. People are inherently lazy, so if you give them that unguarded saw, they ARE going to cut themselves up, as well as their customers. It's one reason why I choose Delphi / Object Pascal over C++/C#. Yeah, it still has sharp edges and you can still write utter gibberish code with it, but it tends to do a bit more to discourage the "running with scissors" syndrome so many ignorant programmers fall into with other languages. That's my personal opinion though; I don't expect anyone to share it.

I think maybe the disconnect here is that people are using "lazy" as a synonym for "simple". Lazy is a state of mind, or an attitude. Simple is a state of affairs. You can simplify things in your life without being lazy (in fact, people who are lazy rarely go to the effort to simplify their lives, and wonder why their lives are so hard as a result). In math, I use simplified equations rather than long derivations, not necessarily because I am lazy, but because they are more efficient and easier to understand.

Yes, I do want to minimize the amount of work I have to do to get things done; I am not going to spend the rest of my life trying to perfect the "ultimate" binary-to-hex-string function. Again, not necessarily because I am lazy, but because I have other things in life that I have to get done, and there is a point at which I can provably say "it is good enough".

I'm not the one coining; "Three great virtues of programming are laziness, impatience, and hubris" comes from Larry Wall. The idea is most expounded on in 'Programming Perl', but this page summarizes quickly, http://www.paulagordon.com/shows/wall/ . The idea is, he was so lazy, and using awk + sed + sh was so much work, that he went and wrote his own scripting language to make things easier on himself.

Yes, it's a slanted use of the word laziness, and maybe I should have left it alone. My point - and to a large extent Larry's point - is that high level features are not bad. Toolkits are not bad. Using the tools you have is a good thing. Building reusable tools is a good thing. The power of computers is in their ability to automate things, including their ability to automate common and tedious programming tasks. When someone starts talking about writing long stretches of code and is disdaining 'dangerous' high level features, it puts me in mind of that quote anyway, and when the word 'lazy' is thrown into the mix... well.

So, yeah. This kind of 'lazy' is lazy like using (or building) a power drill instead of using a hand-cranked one, not 'lazy' like giving a board a sharp jab with a stick and saying 'ah that dimple is as good as a hole'.


Not trusting operator precedence seems very strange to me; if you cannot trust the compiler to implement the syntax of the language, then how can you write anything in that language at all? Of course, this can be carried too far -- if you have to work out a tree diagram on the whiteboard, just throw the darn parentheses in. Although I note, one of the few compiler bugs I have run into appeared only if you had unnecessary parentheses, so don't be so smug about your extra efforts. Something like if((1 + 2) < (2 + 2)) failed where if(1+ 2 < 2 + 2) succeeded. If a compiler is going to fail to parse syntax correctly, it is entirely impossible to predict where that will happen. You have to trust that it will be run correctly until you can isolate the fault to a degenerate case and say 'this proves the compiler is broken.'

(PS: Also, there is no such thing as 100% reliable in a computer program. Under some circumstance it will fail. Most programs will fail under even the most minor memory or disk corruption; even ones that checksum to prevent that have once in an aeon cases where the checking fails. Corruption of the executable code demands having multiple units duplicating efforts, and even those... etc. Heck, your CPU might have a bug when faced with multiplying certain floating point values and all your checksums come out fine, your duplicate units come up with exactly the same wildly incorrect answer.)

All I was asking for was a simpler way to deal with multiple if...else statements. And while I may not be a "real" programmer by any stretch, I have done my fair share of coding through the years.

When you have 20-30 items you need to sort through to call the correct function, if statements become a hassle. This is why switch...case statements were developed. Yes, it makes the lookup go behind the scenes. Yes, I understand that knowing what your language does is important, but there are a lot of things that could easily be abstracted out. Yes, I understand that you lose a level of error checking along the way. I fully understand these issues. I have no problems adding a bit of error checking, or hard-coding the functions list by hand to make sure it works right. If it takes a little longer to write, that is fine as long as the end result is quick and efficient.

The code I wrote for my vendor system would have saved about 125 lines of code just by being able to abstract out the list I used. Then again, I could probably save myself a lot of trouble by not properly indenting or using parentheses and brackets for everything.

Perhaps if LL were to add a switch...case statement to LSL that would help us out. It still adds quite a bit of code, but is easier to understand down the road.

Maybe I'm just a lazy, two-bit programmer.

The issue isn't trusting the compiler. It's trusting the ability of the current and all future maintainers to reliably read a complex expression and remember the correct rules, especially for things like associativity (a - b + c), which can vary between languages. Personally, I take the Sherlock Holmes approach to this. I don't clutter my mind trying to remember the associativity rules for the language, I just put in the parentheses.

I'm aware of the source, but I am also aware the context in which it was used. Laziness by itself is NOT a virtue. Nor is impatience, nor hubris. The desire to front-load extra effort is far from being "lazy", because, again, it is *extra effort*. People, especially IT people, have a tendency to redefine terms to make a contextual point. That's OK; English allows for that, because of its nature. The issue is that, when you are using a colloquialism, you need to impress the context of the point to make sure you don't mis-communicate it. That's why I said that we probably have a disconnect.



Exactly, it is slanted, and without proper, well-defined context, it is misleading. Personally, I don't agree with its use, even in that context; it is simply wordplay; an intellectual mind-game that tends to obfuscate the point, rather than clarify it, especially when related to learning folks.

I've certainly never claimed high-level features are bad. I like things such as OOP. It makes my life easier, and allows me to build even higher orders of structure in my projects that I probably wouldn't otherwise attain in my lifetime. Toolkits are fine, when regarded and utilized properly. Using the right tool for the job is also a good thing. Building orders and structures that you can reuse rather than having to write anew every project is also a good thing (though that often proves significantly more difficult in practice than theory; go figure).



Right, except that isn't "lazy"; that's performing prescient diligence. It's a lot harder to build a power drill to make good, consistent holes than it is to just use that sharp stick to make poor ones. Hence, less "lazy". Maybe you can look at it from the point of view of being diligent in the present so you can be "lazy" in the future, but I doubt that would be the case; with that kind of habit, you would tend to be diligent in other areas of your programming tasks for the same reasons. When you start becoming lazy is when you stop utilizing diligence to continue those good habits.



When you write software that is meant to be portable to other platforms, you may not know in advance what compilers are going to be used, and what, if any, idiosyncrasies they may have. One of the more common borkages in compilers I have experienced is just that, broken operator precedence rules. Some compiler maker either codes a bug, or (more often) intentionally decides that conditional operators should have a higher precedence than arithmetic operators. Yeah, it's nuts, but I have had to code around that stupidity too many times, so guess what? I make it explicit no matter what.

That was part of my point about not trusting stuff other people write; it extends to compiler writers, too. I can easily write code in many languages, but when it comes to trusting the compiler's implicit interpretation of the source code, I don't trust it at all. You see, the problem lies in terms of assumptions and defaults. I don't trust defaults. I don't, for example, trust languages to initialize all my variables implicitly. I ALWAYS initialize my variables explicitly or, if I don't, I consider that a bug, and fix it when I discover the oversight. None of this prevents me from writing code in any language, it just removes one layer of headaches that I have had to deal with. There are still quite a few more, to be sure, but every one I nip in the bud beforehand makes my life easier.



I have seen that myself, but the problem I am talking about is more often the fault of incorrect assumptions about implicit settings/defaults than an actual bug in the compiler. I've seen my share of those, too, though. More often than not, being explicit solves more problems than it causes, so I am always in the habit of using it.



There is a difference between proving the algorithms and code correct, and problems with the platform running them, be they software- or hardware-related. While you can add in exception checking for those cases, too, what I was talking about was simply proving YOUR code being correct. "y = x + 1;" is a provable piece of code, where the result is that you want to assign the value of one integer variable, incremented by one, to another variable. You might think that is a simple example "Who could possibly screw THAT up??", but consider that I have seen people write "y = ++x;" instead for that same function. It isn't the same piece of code at all, and caused a serious buffer overflow error in the program.

Software proofing methods work from simple statements to blocks of statements to functions, objects, modules, and then up to the entire program. Also allows for an easy way to incorporate unit testing, since that can be used as part of the vetting or proofing process.

None of that effort by itself can plan for platform failure, however you CAN incorporate simulated platform failure into your exception handling proofing and unit testing cases to allow your program to have a more graceful way of handling those situations. Nothing can cover all cases of platform failure, though, and applications don't necessarily have to be designed to take them into account if the OS is designed to cope with them.

Sorry, we kind of hijacked your thread and turned it into a discussion about programmer habits, Jim.

LSL is a bit too simplistic for doing very complex things, and it isn't necessarily a reflection on the programmer because of it. You work with what you have. Even still, there are some disciplines and habits which transcend almost all programming languages and programmers, and just are good habits in general. We're just disagreeing on a semantical basis what they are, is all.



Being a lazy programmer isn't a problem. Writing code like one is.

Thanks for the apology. I fully understand the issues at hand when it comes to various programmer's mentalities about good habits and bad.

Most "real" programmers would find my code annoying because of all the documentation I put into it, but I guess I'd rather have everything listed on what it does and what I want it to do than guess at it a month or a year from now.

I really would like a switch statement, however, as it would make coding multiple if...else statements a whole lot easier to both write and understand. At least from my point of view.

BTW, I recently saw something that utterly shocked me: a script where the entire thing was on one line, and all the variables were two or three characters, some of which seemed utterly random. After I regex'd all the semi colons into semi colon + line break, I still couldn't understand what was going on.

Actually, I am a "real" programmer, and would LOVE your code with all the documentation. That's kinda what I am on about, too. Laziness breeds a lot of that situation where people won't even bother documenting anything anymore. THAT's real laziness, and it is most definitely NOT a virtue.

Yeah, I wish I could write code in my favorite OOP language here, too. Life would be soooo much happier for me if that wish could be granted. But, oh well. We make do.

Scripts like you are referring to are often intentionally done that way to obfuscate the code from most casual peeps. It's kind of a poor-man's copy-protection scheme. Well, sorta, anyway.

I just want to say, documented code, and readable/understandable variables, and variables that follow a scheme are your friends! Makes things 100000x easier when after 3 months, something breaks down or is changed, and you look at your script and know exactly what each variable is and what each function does.

Plus copy and pasting code from one script to another is nice too when you have it documented. So from what I've read, keep up the work, keep that habit and don't ever stop.

on a side note: Knew someone in college that got a summer internship at Intel, and wrote some stuff for them. She didn't document the code at all, and at the end of the summer, when she left, they couldn't follow the code that easily, so scrapped the whole thing she was working on.