Articles with a particular focus on objects. Maybe some Python, but mostly Lua.
Lua, by default, compares tables for identity, not contents equality. We would like to do better with Tests. When we’re done with this improvement, tests will diagnose incorrect, missing, and excess values in tables.
Some quick test recipes to get you started, followed by some explanation of what’s going on behind the curtain.
Using the Valkyrie Transport
class()function, declaring a class is easier and less error-prone than directly setting up metatables and such. Here’s a quick recipe for using it.
This morning I plan to show, in small steps, how and why we move toward objects and classes in SLua and other languages that support the object notion. Wish me luck.
I am feeling impatient. This tells me that I need to be extra careful today, but I really want to move a prim along a path.
In which, I consider what I’m up to, and try a different approach, an iterator.
Let’s try that idea for improving
make_waypoints. I have a good feeling about that.
This morning I plan to continue working on my vision of a small number of tiny objects collaborating to track along a path.
There is a school of thought in object-oriented programming that tends to create many very small and simple objects. And there are the other folks.
I’d like to give my Bezier thing a bit of memory.
No, not Pigs in Space, curves. I plan to do some Bezier experiments in Aditi, leading to some motion experiments, distance approximations, who knows what all. Certainly I don’t.
With a language like SLua, we can do a much better job. To do that, we’ll need to think differently from how we think about LSL. Let’s begin to explore the differences.
This morning I plan to build the plan that swaps cars 2 and 3, since doing 1 and 2 worked yesterday. Then we probably need some design and refactoring.
Let’s take another small step toward shunting actions. The plan comes together!!! I am chuffed!
Yesterday we coded up a somewhat sensibly-structured “plan” for swapping the two nearest cars. Today we write some ugly code, with an excellent result.
I think I’m ready to actually code up some shunting. Lots of design thinking here, and a tiny bit of code.
I begin to see how I really want this thing to work, where “really” is a bit iffy. I’m at a point where I begin to see the simplicity that I like to find when I solve a problem. Let’s discuss this.
I have a sort of half an idea for making the testing of plans easier. Let me explain.
This morning I’d like to make a bit of progress toward solving the puzzle. I have at least two ideas for how we might proceed. Overall, I make a tiny bit of progress but not as much as I’d like. I do make the testing setup a bit better.
Let’s take a look and see what we can do that is a step toward some kind of Inglenook Solver. This is made more difficult by the fact that I’m not sure yet just what I want to accomplish. We’ll discuss that as well.
Yesterday, I made a repeated mistake using my current way of creating classes. We need a better way. Let’s have one! WARNING: Parts of this article go deep into metatable land!
Today let’s start on some small classes for Sidings and maybe Cars. (Things do not go quite as I planned. Nothing new there.)
By way of summing up, at least until the next article, today we’ll look at a complete example of a simple SLua class, and a diagram showing where the metatable that makes it work fits in.
I think we have the background now to describe Lua objects and how they work. Let’s try. Let me state our conclusion now and then build up to understanding it:
This morning, we going to take a step toward understanding SLua objects, by discussing the fact that a table can have functions in it, not just data items. That’s the first step along the way to objects: there will be at least one more article about this, and probably more.
Wild idea: What if we didn’t put code in dataserver that knows so much about Person, but instead let the Person handle all the dataserver events? We could have a standard dataserver event that handles many different requests.
Let’s put in the second dataserver-requiring field, the pay info. It will work just like the one for rez date. We’ll proceed in tiny steps. Each step, we’ll try to put in the code that best deserves it.
The tricky bit in the homework is the dataserver bits. Let’s get started on that part.
This morning, we’ll start with a very small refactoring, and then produce the first draft of our desired report. At least that’s the plan: plans often go awry.
As an exercise, I am going to try to implement an object-oriented solution to the homework from the SLua class of April 16, 2025. Let’s start with some introduction to objects.