Extensions: lazy initialization?

Hi there,

it looks like the init function of an extension only gets called, if I call another function of that class?

I wanted to put some housekeeping code in that function, that gets executed when I open the TD file.

But at the moment it looks like I have to call that function explicitly, if I want it to happen for sure.

Is that correct?

Best wishes,
David

Could you use an Execute DAT instead? Maybe you’d use the onStart or onCreate method?

Thanks for your suggestion, that’s what I currently do.
But since there are many of that OP’s, it would be nice to not have to initialize them one by one.

Hey David,

That’s correct. These days the way I that typically handle these kinds of challenges is to give each component in a project it’s own extension. From there an Execute DAT just calls a simple OnStart() method for the first in line which then does the clean up and initialization for other modules.

Practically that looks something like:

op('base1').OnStart()

base1 calls base2 calls base3 calls base4 and so on. Depending on the module the init script method might do all the clean-up and prep, or there might be something more complicated that goes into that OnStart() method for a given module.

Here’s an example that’s pretty abstract but holds focuses on the idea:
init_example_one_extensions.toe (4.36 KB)

There’s a lot of repetition here, but the big idea to see is that the Execute DAT only makes one call which then cascades down through classes in order.

This particular example could be cleaned up with some inheritance, but that’s not really the meat and potatoes of this example… instead what this is helpful for seeing is the cascading nature of these calls, and how you might use the init() method in setting up a project that needs larger forms of configuration.

Hope that helps.

It’s also worth pointing out that if you pulse the reinitextensions par the init() method will fire.

It’s worth noting that you can use this to your advantage by giving your top level object an extension - the init() method will get called after all the usual Touch start up procedure is done which can help work around some ugly tricky coding. This also means that you don’t need to use an Execute DAT as the extension for the project will be initialized.

Here’s what that variation looks like:
init_example_project_ext.toe (4.22 KB)

This is one of my favorite tricks these days as it lets me do exactly what you mentioned - set the specific init order of your project with any appropriate cascading calls that are required.

Hope that makes sense.
M

Hey Matthew,

that makes total sense and is really helpfull.

If I got this right the init function of the top level operator (in this case “project1”) will always get called. So I can cascade my setup functions starting from there.
It is also good to know, that this initial call to project1 happens after TD’s start up procedure is done, so there won’t be any interference from that.

I really appreciate you are taking the time and effort for making this great examples.

All the best,
David

This has been my favorite approach so far - the onStart game is a hard one, and taking advantage of that top level OP’s extension getting initialized on start has saved me a ton of headaches.

Glad it all made sense. :slight_smile: