Re: [racket-dev] [racket-bug] all/12861: promise/c does not maintain equality
On 2012-07-11 11:33:39 -0500, Robby Findler wrote: > 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? I'm not sure this would work because the user interface for inserting the data into the property is via the #:property or #:methods arguments in the `struct` form. The guard seems to be the only way to add any checking there (without wrapping or modifying `struct`). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket-bug] all/12861: promise/c does not maintain equality
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 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
Re: [racket-dev] [racket-bug] all/12861: promise/c does not maintain equality
(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
