4 ms·

C# code still uses too much reflection (serialization, asp net routing, ORM, view model binding) to be statically compileable. They seem to be doing something a

C# code still uses too much reflection (serialization, asp net routing, ORM, view model binding) to be statically compileable. They seem to be doing something against that with code generators

voxic11 6y ago
Reflection isn't an issue. CoreRT allows you to include the symbols for reflecting on though it does increase the filesize significantly.
- vips7L 6y ago
  The trouble comes in your dependencies when you don't know what they're reflecting upon or what features they're using that aren't supported.
- randombytes6869 6y ago
  This is exactly what newer versions of Java allow you to do. The problem is, nobody does it. I really like C# as a language, its better than Java in nearly every way. But this is a rare case where C# is implementing a feature Java has had for a very long time. And just like in Java, I don't think it will have the impact advertised.
Ididntdothis 6y ago
The funny thing is that a lot of reflection is made necessary because of the lack of a preprocessor. Considering that everything old comes back after a few decades as a new innovation with a shiny new name I wouldn't be surprised if the preprocessor came back to support static compilation.
randombytes6869 6y ago
C# and Java are both guilty of this. I don't think generators will help nearly as much as hoped, because Java has the same problem even though it supports build time code generation through Annotation Processors for like over a decade, since Java 7 I think. Reflection is just easier. Unless you go out of your way to use libraries that use code generation, Java is just as bad as C# in this regard. There's a few bright spots, like MapStruct for object->object mappings and Dagger2 for dependency injection that are built entirely on code generation. But these are exceptions to the norm

4 ms·

C# code still uses too much reflection (serialization, asp net routing, ORM, view model binding) to be statically compileable. They seem to be doing something a

by legulere 6y ago

C# code still uses too much reflection (serialization, asp net routing, ORM, view model binding) to be statically compileable. They seem to be doing something against that with code generators

voxic11 6y ago
Reflection isn't an issue. CoreRT allows you to include the symbols for reflecting on though it does increase the filesize significantly.
- vips7L 6y ago
  The trouble comes in your dependencies when you don't know what they're reflecting upon or what features they're using that aren't supported.
- randombytes6869 6y ago
  This is exactly what newer versions of Java allow you to do. The problem is, nobody does it. I really like C# as a language, its better than Java in nearly every way. But this is a rare case where C# is implementing a feature Java has had for a very long time. And just like in Java, I don't think it will have the impact advertised.
Ididntdothis 6y ago
The funny thing is that a lot of reflection is made necessary because of the lack of a preprocessor. Considering that everything old comes back after a few decades as a new innovation with a shiny new name I wouldn't be surprised if the preprocessor came back to support static compilation.
randombytes6869 6y ago
C# and Java are both guilty of this. I don't think generators will help nearly as much as hoped, because Java has the same problem even though it supports build time code generation through Annotation Processors for like over a decade, since Java 7 I think. Reflection is just easier. Unless you go out of your way to use libraries that use code generation, Java is just as bad as C# in this regard. There's a few bright spots, like MapStruct for object->object mappings and Dagger2 for dependency injection that are built entirely on code generation. But these are exceptions to the norm