> I agree that generally don't want performance declarations that > interfere with reasonable interposition. The good uses of `#:authentic` > would be in places where the struct representation of a value is not > exposed or where the values themselves are not exposed (so any > interposition means being on the "inside" where you can change the > code, anyway).
Yes, I agree with this. I think as far as how this changes Racket’s data abstraction model, the key is “where the values themselves are not exposed.” #:authentic only has an interesting effect in the other case, where “outside” code gets its hands on a value of the struct type. Previously, I could write a program that used inspectors to impersonate this value regardless of the “inside” code’s intent. Now that would no longer be possible. I doubt there is much code that currently relies on being able to do this and so I would say go ahead. (Perhaps DrRacket or other debugging tools?) On the other hand, Spencer already asked if this would be something the optimization coach would recommend. I think it would be important for the documentation of #:authentic or the implementation of such a coach to stress the importance of the rules of thumb you just laid out. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/3c430798-e93a-4900-8215-198f77d9b991%40Spark. For more options, visit https://groups.google.com/d/optout.
