[Refactoring] Convert EventFunctionsExtensions to a PlatformExtension in Core (not in the IDE) (C++)

[arthuro555]

Something I don't fully get is why the eventsFunctionExtensions are converted into a PlatformExtension by the IDE (in newIDE\app\src\EventsFunctionsExtensionsLoader\). I've always thought that would be the kind of thing that are inside GDCore, and this makes the full usage of GDCore depend on code from the IDE, making it hard to reuse outside of the IDE or if to rewrite the IDE again (if we ever need to).

[4ian]

This could in theory be in GDCore itself indeed, I kind of agree. This was probably simpler to do in the IDE because of the need to write files (if made in GDCore, EventsFunctionCodeWriter should be passed like AbstractFileSystem, with functions implemented in JavaScript).

In which case is this a problem for you?

[arthuro555]

It isn't really an issue, though I do am a bit worried that the "GDCore loader" I made might break as I hardcoded those files in but that would be my own fault for not extracting those files from github.

I was more worried about code quality, as it might make it harder for contributors that would want to work on this, as they'll likely search for those files in GDCore but won't find them as they areactually in the IDE. Generally blurring the line between GDCore and the IDE makes the difference between both that one is in C++ and the other in JS, resulting is some spaghetti code split in two entangled projects in different languages, which isn't very friendly for contributors.

[4ian]

I've marked this as a Good First Contribution. It's a medium amount of work (not trivial though), in C++. It's a refactoring so not bringing immediate value by itself, but could be interesting.
Need good design to be validated with me to see how we expose file writing (or upload, for the web-app) thanks to JavaScript (like done for AbstractFileSystem, but simpler)

[arthuro555]

Couldn't we use directly the AbstractFileSystem for that purpose? Why add a new abstraction for writing files if we have one already?

[4ian]

We could but it has to be carefully considered. Because AbstractFileSystem is geared toward export for now (we could almost rename it ExportFileSystem).
It's easier to use and evolve two separate abstractions rather than a single one that is cumbersome to use, and that make you risk breaking the export when you're modifying the events function (and vice versa).

In this case, the events function needs basically to just write files (a bit more, but that's mainly it). So it could make sense to keep them separated.