blaze,
Yes, modules are very roughly analagous to objects.
That said, there is a ton of difference between a module-as-object and a class, or even a normal standard programming object.
Note that a class is different from an object. A class is like the mould for a car: it describes how to make a car. An object is an actual real created thing, something like a car itself.
An object offers encapsulation: it hides implementation details from users of the object. A module does that.
An object offers public methods (and often properties) that a user of the object can call. A module does do that, via LinkMessages, but its really a pain in the butt to use since the calls are only asynchronous. Whether technically this counts as public method calls is debatable but its certainly the only "oop" system I've ever seen with async calls...
Classes offer inheritance. In SL, well I guess you can call a script in your inventory a class to the extent that you can rez tons of them. Inheritance would imply that you could take a script you had already written (a "class"
and extend it: add new methods. Arguably you can sortof simulate this with LinkMethods but again its kindof dubious.
As a summary, yeah you can use a script as an object, just as you can use a C module as an object. It's even more similar to a real object than a C module, since you can rez it multiple times without having conflicts in global module variables. You can probably simulate inheritance with LinkMethod passthrus and so on, but on the whole the async nature of "method" calls limits the useability by at least an order of magnitude (in terms of ease of use and speed of implementation).
To get even a chance of pretending to have OOP, we'd really need:
- includes (well, not sure if they really change the nature of OOP, but would certainly make our life easier, reduce configuration control nightmares)
- more script memory (includes are useless if your script stackheaps)
- synchronous method calls to other scripts
Azelda