Implementing serialisation with minmal boilerplate and template overhead using core.reflect

[Arafel]

On 17/8/21 22:50, Alexandru Ermicioi wrote:
> On Tuesday, 17 August 2021 at 20:23:48 UTC, 12345swordy wrote:
>> On Tuesday, 17 August 2021 at 18:10:48 UTC, Alexandru Ermicioi wrote:
>>> On Tuesday, 17 August 2021 at 14:16:52 UTC, 12345swordy wrote:
>>>> The reason that they use runtime reflection in java/c# is because of 
>>>> the basic principles of OOP.
>>>>
>>>> -Alex
>>>
>>> How does basic principles of oop force java implementations use 
>>> runtime reflection???
>> https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)
>>
>> You cannot obtain information such as "How many child classes does 
>> this class currently has", without compiling every code/library that 
>> you use, which isn't feasible as not every library share their source 
>> code.
>>
>> - Alex
> 
> I still fail to see relation between oop and runtime info use. The part 
> about source code sharing is also true for c and d libs, which both 
> could share only header files and have pointer to struct declared 
> without said struct declaration (i.e. Opaque struct type, not sure 
> completely about D though).
> 
> The thing is, that runtime reflection in java is more or less usable 
> compared to d (sigh), and can be used to design libs that are using that 
> data to do their job, but this doesn't mean that there aren't any 
> options on using compile time info to generate or alter compiled code. 
> Take for example lombok project, jpa model generator from hibernate, or 
> mapstruct library which is a mapper from one java type to another (kinda 
> close to serializers), all of them are used at compile time to either 
> generate new code, or alter existing one, based on annotation processor 
> plugin feature offered by java compiler, not to mention byte code 
> enhancement capabilities, and libs using them.
> 
> I'm pretty sure C# has similar possibilities, for code generation and 
> alteration.
> 
> Regards,
> Alexandru.

There's at least a use case that can only be solved with runtime 
reflection: dynamically loaded code (so, dlopen or similar) where no 
source code is available at all, for example if you want to implement a 
plugin system.

For sure you can have the code "register" itself, and add some kind of 
"description" or metadata, but if you want for instance to implement a 
persistence / serialization system in such an environment, you end up 
all but implementing your own version of runtime reflection.

I don't have that much experience with that, but I think that separate 
compilation could also have issues, for instance if you want to 
distribute your program in binary form, and still allow people to 
compile plugins / extensions for it.

A workaround might be to distribute enough of the source code in the .di 
files, but I'm not sure how workable this would be.