Replace static field initialization in typed types

[back2dos]

Would it be possible to allow replacing static field initialization in already typed types under certain circumstances? I think it should suffice for the field to be physical and not be inline.

The main motivation is to be able to put data somewhere that has been accumulated by macros without having to resort to resources or metadata: https://groups.google.com/d/topic/haxelang/zqpQI2t0DwI/discussion

For complex data the only way to do it now is to use resources, which requires haxe.Unserializer in the output and that adds quite a chunk, i.e. all the compat stuff, all the reflection metadata, for nothing. On JS it does make quite a difference.

[Simn]

I don't like the idea of changing type structures like that, it adds a whole new layer to what we have to keep in mind for internal development and I have no idea how the compilation server would react to it either.

I think you can already achieve something quite similar by defining a new type in onGenerate and pull some extern/@:native tricks with it. That means the static field is on another type, but that shouldn't be a problem. If onGenerate doesn't do the trick then the solution to #4714 is going to address it.

[back2dos]

I don't like the idea of changing type structures like that

My very point was to allow it only in cases where it does not affect the structure. I fail to see why replacing a value would affect the structure, so long as having a value is valid at all (i.e. the field is physical) and changing it does not affect any other module (i.e. the field is not inline and the replacement occurs before DCE). Would you please indulge me and explain to me what side effects there are under these circumstances if you type a new expr against the known field type and (assuming no type errors) replace the old texpr by the new one? Thank you.

[Simn]

My very point was that I don't want to think and worry about replacing expressions in typed types because it adds complexity. The existence of the compilation server alone is enough for me to turn this down, but even without it there's a lot of critical ordering going on in our post processing. For instance, onGenerate runs after important filters like rename_local_vars and the analyzer transformations which could easily lead to problems on various targets.

[back2dos]

Ok, thank you, this gave me a vague understanding.