Talk:Object Oriented LSL

The perspective of having some kind of OOP support in LSL is really exciting, and such a feature would definitely come as a relief to experienced programmers. However, from what I understand about LSO, I'm afraid it would require more than just "some tweaking".

There are just too many intrinsic limitations with the current implementation of LSO; it makes absolutely no provision for classes support, the closest thing you might get to references are heap pointers; not to mention the fact that LSL scripts are self-contained, which means you can't access members (functions or variables) across scripts, etc...

At the very least should a couple of new opcodes or built-in functions be implemented, that would pop a key (as a class reference) and a function number (as a member method reference) from the stack, and then call the appropriate function (same for variables). I'm talking classes and not objects here, because you wouldn't have any instantiation mechanism anyway, so it would be like working only with full static classes, all the way.

Before you could even start dealing with common OOP features, such as inheritance, access protection issues etc., you would have to get a significant amount of work done on the VM just to get the basics right.

It's such a shame that the original LSO implementation was so poor, a better implementation could have led the way to many interesting and challenging opportunities, like translating Java bytecode to LSO, using design pattern constructs such as interfaces, listeners, etc... right from the start, and thus promoting good OOP practice.

So let's just wait for Mono integration now, and hope for the best.

-- Suleyman Polikarpov 10:28, 10 December 2007 (PST)

Not to mention that the 16k limit. The overhead of classes would be horrendous. By the time you had everything defined you would have used up most of your memory. -- Strife Onizuka 23:32, 10 December 2007 (PST)

I believe it is already possible to approach lsl scripting in an object oriented way. Be it in a more literal sense than most scripting/programming languages. If you come to think of it, every prim is an object. And then I mean it in the programming sense of that word. A prim already has 'batteries included' attributes (shape, color, name, description, id, etc.) and methods (llSetPos/llGetPos/llSetLocalRot etc.). You can even regard 'on_rez' as an overridable '.__init__(self)' method. You can communicate to prims by using 'llListen' and 'llSay' in a very easy straightforward way. You are actually creating an instance by rezzing a prim. You define classes by designing new prims and you instantiate them by rezzing a copy of that prim. You add and override methods by dragging scripts to them. I'm actually happy I don't have to spend a lot of time defining a new class before I can make an instance to it. It happends simultaniously in SL. and if you really want to do classdefinitions you can create a script that rezzes your prim with all the desired values for you.

Only thing I miss using prims as objects (but I have seen another feature request for it) is more elaborate 'root'-'child'-linking functionality ... And an easy/documented way to write/edit notecards ... Just my thoughts ... Bayru Jiagu 07:11, 25 January 2008 (PST)