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)