seems like it should work? Of course you have to make your class constructors look for it… the language won’t inherently take an anonfunc as a constructor argument…
That works, but at that point I don’t think you’re saving much typing over doing it the way you do it without a builtin initializer pattern, something like:
local obj = new SomeObjectClass();
obj.foo = 'foo';
obj.bar = 'bar';
And stylistically using a function there is a little awkward because it makes it difficult to pass the configuration object to multiple functions/methods to twiddle individual properties, a la:
local cfg = object {
foo = 'default',
bar = 0
};
// Maybe twiddles cfg.foo
globalConfigFunction(cfg);
// Each increments cfg.bar by some amount
forEachInstance(ImportantClasses, function(o) {
o.localConfigMethod(cfg);
});
local obj = new SomeObjectClass(cfg);
…where the idea is that you’re starting out with a default config value, applying some global constraints/checks/whatever, and then allowing individual objects/subscribers/whatever to tweak the config. That’s the sort of case that lead me here…a factory singleton that cobbles together a config based on various elements of game states and then coughs out a instance configured appropriately.
For that sort of thing I’m leaning toward allowing an anonymous object as an argument to the constructor, and the having the constructor iterate through the properties on the object and/or creating an instance of a dedicated config class that does so. In addition to allowing multiple callers to decorate the config object, that also has the advantage of encapsulating all the logic in one place.
Yeah, like I mentioned above putting together a factory singleton (specifically to handle setting up in-game card games) is the reason why I started the thread.
I started out with a method on the factory object that just had a very long argument list. That started out working…adequately. But as the number of arguments and the number of test cases increased, it rapidly evolved into something where I had to constantly check my own notes to keep the usage straight. And even then I was routinely ending up spending time debugging things that turned out to be because I’d reversed the order of two arguments or whatever.
Anyway, the sort of thing I’m leaning toward using now is something like:
Note though that if you misspell a property (or method) name, you won’t get an error. Instead, a new property/method will be defined for the created object.
Inline objects seem to have a lot of promise, but I have remained gunshy of using them, because I tried using them early on and ended up with freakish errors that seemed to be in the VM or memory allocation. Since then I’ve just gone straight to finding ways to code things without them.
I’d like to believe they could be reliable, though…
I think I might use the “complicated constructor” method instead anyway (just to be able to catch/flag cases where the config object wants to set a property that isn’t part of the config’d class’ definition) but that’s good to know.
Yeah, you need to think about it as dynamic object definition rather than just instantiation. Just like you can misspell an identifier in a normal, top-level static object definition, you can do the same here. But sometimes, that’s exactly what you want for stuff like:
Yeah. In my case I’m mostly worried about “pure” instantiation/initialization usage for testing purposes: creating a bunch of instances by starting with a “base” config and then iterating through a bunch of variations, to run tests on all of them and comparing the results.