Closed nadinengland closed 11 years ago
That's a very clever little hack. In response to this, and also into the verbosity of the previous technique, I've gone with the old-school 'privilaged method via closure' technique:
i.e.:
I'm going to close this, since I think it solves this level of vunerability :) I didn't previously understand why your sealer worked as it did, so that little hack was super informative.
Why is this a concern? It wouldn't ever be mutated by accident would it?
No - but if you have truly immutable data (i.e. a guarantee that no third part could possibly mutate it), then you can entirely eliminate a class of possibilities when debugging/reasoning about application state.
It's far more a peace-of-mind thing than anything deeply practical, admittedly.
oh yup thats pretty much what I thought it would be and I like the guarantee too. Its just a bit too much of a performance hit for my taste.
Privileged methods work like a charm! Glad it was able to shed some light on this.
@jkroso : not a decision I'm 100% happy with. It may be worth benchmarking this solution later against the alternatives - deep freeze and something like @nadinengland's privy.
@nadinengland : ^^
It is possible to access the internals of an immutable object by exploiting calls to
this.['-data']
.I know immutable states nothing about the security of immutable objects, and I'm not trying to preach my own stuff ;) but raising it as an issue as immutability can be by-passed.
If this is a moot point please close.