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.