This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
Date: Sun, 08 Jan 2006 11:30:30 +0100 From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> There are many issues here, but I will say this for now: the opacity model in the SRFI is not intended to provide any kind of security feature. The Rationale section states this quite clearly. Right. I think, though, that security is a real and justifiable motivation for features, whereas the enforcement of opacity to impose abstraction barriers, well, goes against the whole point of the reflection layer in the first place. There are illegitimate uses of reflection, but there are also illegitimate uses of source code to find unintended properties that other code can rely on (and thereby become very fragile). If you're worried about violating abstractions, you shouldn't use reflection -- but if you have a good reason to cross abstraction boundaries, such as to write an object inspector, then there is no reason for the implementation of the abstraction to inhibit this (except security, which is a different issue altogether). (This all assumes the existence of the reflection layer in the first place, of course. What does opacity of record types defined with DEFINE-RECORD-TYPE mean if there is no reflection layer, which I assume could be the case if the SRFI were separated into parts and the reflection layer made optional?)