3 ms·
> (e.g., "given a DOM node, traverse all of its children") you can use a library of transformations ... and write queries and transformations over arbitrary str
by pron 4y ago
> (e.g., "given a DOM node, traverse all of its children") you can use a library of transformations ... and write queries and transformations over arbitrary structures in a very compact way.
But in Java you'd do that with reflection. So the question remains, how many such different queries/transformations you actually have (in the source code, where type checking is available, rather than user input) to make the effort-saving worthwhile?
- chowells 4y agoMaybe you would rather do that with reflection, but I'd rather do something that isn't fundamentally the same tools that create security vulnerabilities. Every time you can not-use reflection is a win.
- ivan_gammel 4y agoI think there’s some misunderstanding between the two of you. Reflection is indeed the sane and convenient solution for working with structures when type is not known at compile time (e.g. general purpose library for DI, ORM, security or serialization). It’s definitely not the way to manipulate object trees when type is known in compile type. However the point about complexity is valid: is it really worth patching strongly coupled solution violating SRP and breaking encapsulation with some design pattern for an anti-pattern (setters)?
- pron 4y agoRecords were specifically designed for safe reflection (and safe serialization). What causes security vulnerabilities is so-called deep reflection, i.e. the use of setAccessible, and can then violate various invariants. That's not what I'm referring to here. Reflection ≠ deep reflection.
- kqr 4y agoPart of the convenience is in having uniform syntax for data access and modification, no matter what the target is. Is it "worthwhile" to use this when you have it? No doubt in my mind. Is it worthwhile to add a build time dependency for it? Maybe depends on application.