Hacker News new | ask | show | jobs
by alkonaut 526 days ago
I think the agreement is rather “if you change the private field then there are no longer any guarantees of anything”. Which is fine, I think. And obviously with or without reflection anyone can already modify the private field.
1 comments
Quekid5 526 days ago
It's the shortest path to Hyrum's Law, certainly.

> And obviously with or without reflection anyone can already modify the private field.

This bit, I don't understand. Wouldn't that require unsafe?

EDIT: Just to say: Abstract data types usually require upholding some invariants which all the operations on those data types must uphold at entry/exit. If anyone can do whatever, then what's left othen than just a bag of bytes?

link
alkonaut 526 days ago
Yes. I’m 100% talking about unsafe Rust now (for private fields).

That is: I see reflection only as a way of making unsafe bytemucking a bit more ergonomic. Its nothing you can’t already do. It’s a well behaved object with invariants 99% of the time, then for some edge case/cheat it’s not. Much like the difference between safe and unsafe already is. Most of the time you rely on the guarantees, but occasionally you throw the guarantees out. And again: this IS already in an unsafe context by necessity. This has been the case in every language with encapsulation and reflection (C#, Java, …) since forever. And it’s a super useful thing. I can’t see why the encapsulation in (unsafe) Rust is more important? Is it because it has no runtime to provide guard rails where the JVM/CLR would still throw exceptions when I use my tampered object with broken invariants?

link
Quekid5 525 days ago
Oh, I see...

I think I was thinking about reflection in an entirely different way. When I think Reflection I think mostly static and generative reflection -- so you can introspect on data structures, derive [whatever] from that, generate code, whatever... but you still cannot do [whatever] to the thing you reflected on. (Other than whatever the language says you can do as a public consumer of that API/structure)

So you can, say, add serialization code, generate property test instances, whatever.

What you cannot do is do anything to "invade" the thing being reflected on and change its meaning.

link
alkonaut 524 days ago
This sort of thing seems you should be able to do already at compile time instead of using reflection?
link