If you're limiting access, could you provide a function-based interface that wrapped the impersonating procedures to add the checks instead of using a guard?
Robby On Wed, Jul 11, 2012 at 11:25 AM, Asumu Takikawa <as...@ccs.neu.edu> wrote: > (sending this e-mail to dev since it's not directly related to > promise/c) > > On 2012-07-10 22:13:58 -0500, Robby Findler wrote: >> Note that this means the guard on there is now going to be gone (as it >> is meaningless since impersonators can arbitrarily change it). > > This is something that has confused me about impersonators on struct > type property accessors. It seems like there is a use case for having an > impersonatable property that still has a guard. > > For example, suppose the property and its accessor are defined and > retained local to some module (for example, to store a generic method > access table). This means that nobody outside of the module can > impersonate the property through the accessor. > > Assuming your module itself upholds whatever invariants you expect of > the property guard, it's not going to be arbitrarily violated. For > example, with generics it might be desirable to have optional > polymorphic contracts applied to methods in the method table. > > Since polymorphic contracts are impersonator contracts, the proxy on the > method table property itself must be an impersonator. However, this > impersonation doesn't violate the invariants of the method table > property guard, which just ensures that the user provided valid methods > for the method table. > > Maybe I'm missing something obvious though? > > Cheers, > Asumu _________________________ Racket Developers list: http://lists.racket-lang.org/dev