Newbie question....what’s with the complication?

I have been reading the specs on the Linden Scripting Language and viewing some of the samples and library posts.. Why is everything so raw? I find it more effective to use an object oriented style of scripting, for instance; instead of:


Code:
[left]llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION);llStartAnimation("sit";[/left]



It makes more sense to:
Code:
[left]integer SitError = LLAPI.GetOwner.StartAnimation(LLAPI.Animations.Sit); if (SitError > 0) { //tossError }[/left]


More control is available that way.
I could script this simpifying code myself if "this" (or 'me') were available.
from what I am reading I cant use the use the familiar syntax of a c/Java style language 'this' syntax as in:

Code:
[left]void LLAPI() { this.GetOwner = GetOwner(); // get my owner object/function. this.GetTime = llGetTime(); // easy association }[/left]



So I must create “instances of geometry” for each object just to simplify coding? is this correct?
Why is this not thought out from the start? I was taught that standard application architecture is to design front to back. Not middle meat and the backend then add the API.

It makes more sense to me to have this.owner().startAnimation("sit"; instead of just using OO constructs for namespace management.

If you're designing an OO language, anyway.

If you're not designing an OO language, of course, you make other decisions.

And... LSL isn't an OO language.

So I guess it makes sense that they made other decisions.

Raging, I think maybe you're attributing too much to "dot notation".

Yes, object orientation is a very powerful tool, with very many features that I love and enjoy. But it is not "more sensible" - or easier - and it does not give you any more control than your average non-OO language. (I remember when C++ was little more than a translator that generated C code)

Also, OO isn't really OO without things like inheritance, controlled access, virtual functions, polymorphism, etc etc etc - which tend to add enough overhead to a system that our little 16K memory space, already quite tight, would take an unacceptable hit.

The example you have presented shows little more than dot-notation, which is object-orientation in much the same way that a steering wheel is an automobile.

As a state-based, event driven language, running in an environment that allows tens of thousands of varied residents to all have their software running within the system, many, many, many within the same sim - LSL is, I believe, actually quite awesome.

Give it a chance. You'll soon realise that the major problem with LSL - is the editor

I agree with Raging. However I am not sure the code snippet Raging provided makes syntax of the code easier to understand when compared to the typical SL syntax.

I find that a lot of programmers get way too fancy with the code taking out so much for the sake of brevity and code athlecism that in the end a couple of months later neither they nor anyone else can understand a thing when they review the code.

Please do not over-abridge/compress/fancify your code; At least not the code you're intending to share with us. For everything else, you can even forego linereturns for all I care.

Cheers,

Troy

OO is good when you don't care about cpu time & memory footprint. With LSL these are both comodities that must be conserved.

Is there a memory cap? 16K memory? where does the script run? server and/or client?

16K memory per script, which includes bytecode, heap and stack. Scripts run on the server, typically along with thousands of other scripts. Resources in general are stretched pretty thin, so generating lots of events or spending a long time in code will almost always result in your script running slower than intended, which will throw off any synchronized actions you may be trying to achieve. Welcome to embedded programming.

The limit is 16kb, and the script runs on the server... sending the results to the client.

http://secondlife.com/badgeo/wakka.php?wakka=llGetFreeMemory

LOL llGetFreeMemory: "As of SL 1.6.4, this function remains broken!"

I assume that's 16KB per script, and not, say, 16KB total script usage per agent per sim?

It appears to me that the client does LSL compilation, and sends the bytecode output to the server -- Where it runs. (Judging from the way it handles recompiles...Why would it need to download then upload the script again if it didn't do this client-side?)

As for OO, since when has a non-OO-based language stopped us from writing OO-style code? Just as you can bang out non-OO code using C++, you can easily write OO-style code in C99. I eventually switched to C++ when I realized that all of the funky function pointer tricks I was doing in regular C could be automated by the compiler. (Because, really, that's what virtual functions end up turning into anyway, just a bunch of references.)

Admittedly, I can't see how to write OO-style LSL due to the lack of direct pointer access... Direct access to the VM and the ability to hand-assemble opcodes, that might be a different story entirely.

But then you'd have someone banging out SL code using, I dunno, a Brainf*ck or BASIC compiler. ^_^ Is this the sort of horror we wish upon the world? I'm having second thoughts about this Mono conversion...

Yes, OO is all very well when you have many megabytes and are one of only some tens of processes in the system

When you are very small (16K!) and are running with (potentially) many THOUSANDS of other processes. It changes your perspective.

I spent 6 years writing realtime embedded assembler for domestic alarm cctv and telecoms products. and can quite understand the constraints.

And as far as the editor goes... "a pox on its eyes!"

There are a couple of things missing.

One I would DEARLY like is the ability of a script to know WHERE its prim was touched.

AHH, I *THINK* I understand, touch is worked out in the OpenGL side and so brings back the id of the object, not the point of intersection.

Ok, I'll stop asking.