Extensions, episode XXXXII

who needs an extension mechanism when you send a blob?

Well blob customization has some drawbacks: • more build fun • no “after-market” customization (short of re-upgrading) • won’t help in reuse of extensions across tools

I’m currently leaning toward: • an operation allowing to register new operations, • a public unrepl/write var to allow tagged machine-readbale output • a load-on-first use helper

so a typical scenario would be: 1/ send blob 2/ send extensions map 2bis/ start sideloader

The benefits of extension over direct function calls are: 1/ lazy loading 2/ concurrent implementations (of the same extension) without having ns clashes

Looks interesting

What would be an example of an extension in your view? Just to make it more concrete

I'll give this more thought when I'm back in Berlin at the end of next week

I'd love to think through an end to end example of how this would be used in practice

@pesterhazy basically extensions would be merged in the actions map

@cgrand the load on first use helper is like the jvm classloader right?

It would just be a macro that ensures the ns is required. That's all.

It wouldn't ask you to supply the code for the op?

Of course through the sideloader.

would it be useful to produce a sequence diagram of the extensions & sideloader?

Certainly. I'll draw it tomorrow.

The sideloader is just a network classloader. So all missing classes or namespaces go through it.