On Wed, Jul 2, 2014 at 11:56 AM, Matt Oliveri <[email protected]> wrote:
> On Wed, Jul 2, 2014 at 11:50 AM, Jonathan S. Shapiro <[email protected]> > wrote: > > Yes. The "seal" operation, in its essence, is existential encapsulation. > The > > unseal operation, in its essence, is existential open. The subtle > difference > > between unseal and existential open is that unseal requires an additional > > parameter demonstrating proof of authority. This notion of "guarded > > existential open" is very powerful, and nearly free from a language > design > > perspective. > > What an interesting observation! It's exciting how well object > capabilities plays with type systems, considering its "heretical" > untyped OO origins. I hope to investigate the connection in detail > someday. > Oh dear no. Capabilities and OO seem to have been convergent evolution. Capabilities came in with Fabry's "Chicago Magic Number Machine" in 1967. OO arguably traces to Simula67, which evolved independently by Dahl and Nygaard in Norway. What I find really interesting is just how small and subtle the core difference is, and just how many PL designers have failed to notice the connection between encapsulation and protection boundaries. It's really very startling. The earliest capability systems were tied to hardware mechanisms, which can be viewed as typed at some very low level. > > But getting back to your question, my intention is that interfaces will > be > > the only mechanism of existential encapsulation. > > So than no direct access to private fields of another object of the > same class. Gotcha. You're making an assumption that the entire notion of public and private fields isn't hopelessly boogered... :-) shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
