Fork me on GitHub
#unrepl
<
2017-09-14
>
cgrand09:09:31

Extensions, episode XXXXII

cgrand09:09:43

who needs an extension mechanism when you send a blob?

cgrand09:09:55

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

cgrand09:09:56

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

cgrand09:09:52

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

cgrand10:09:23

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

pesterhazy12:09:42

Looks interesting

pesterhazy12:09:22

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

pesterhazy12:09:48

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

pesterhazy12:09:40

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

cgrand12:09:49

@pesterhazy basically extensions would be merged in the actions map

dominicm16:09:33

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

cgrand17:09:10

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

dominicm19:09:08

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

cgrand19:09:09

Of course through the sideloader.

ghadi19:09:42

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

cgrand19:09:37

Certainly. I'll draw it tomorrow.

cgrand19:09:35

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