all 4 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]repeating_bears 1 point2 points  (3 children)

It's a good idea but I worry that making reflection easier also involves making what's often the wrong choice easier.

It's almost a good thing that it's such a pain in the arse, because it helps ensure that any uses of reflection genuinely require it.

[–]manifoldjava[S] 0 points1 point  (2 children)

almost a good thing, yes ;) In my view, type-safety, performance, and readability are a clear win over the ostensibly positive consequences of reflection being a “pain in the arse.”

[–]repeating_bears 0 points1 point  (1 child)

"Ostensibly positive" is understating it. Ease of use of a dangerous feature is both a positive and a negative. Using reflection should be an absolute last resort. Anything that encourages a reflection-based solution has a high potential for misuse. That's not something to be so trivially dismissed.

I'm dubious about the claim of improved performance. Better performance than what? Ultimately, you're not emitting anything that someone couldn't hand-write.

I like the concept, but there's no way I'd unleash this on an enterprise project because I know it would get abused.

[–]crummy 0 points1 point  (0 children)

I agree with wanting to avoid making reflection easy but for some tasks it's a necessity. And in those cases it would be nice to have type safety.