[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A (Low-Level) Opaque Object Proposal for R5RS

Providing an opaque object facility separate from the record facility
may satisfy those whose primary concern with lack of opacity is one of
security, but it does not address my concerns.  My primary concerns
involve ease of programming and ease of optimization, or more
generally, ease of program analysis.  I discussed how opaque records
support program analysis in an earlier note, so I won't repeat myself
here.  The proposed separate opaque object facility will not yield the
same benefits, for at least two reasons: (1) with the passkey
mechanism, it will be very difficult to determine all points where
access to an object may occur, and (2) programmers will likely neglect
to use the separate opaque object facility when they construct records
because of the added syntactic and conceptual baggage and (likely)
performance hit.

It may be that we should consider including a separate, secure opaque
object facility.  If so, I propose that we first add some form of weak
pointer and allow programmers to implement their own opaque object
facilities in the manner Bill has outlined.  If the facilities appear
to be widely used, we can then include some variant in a standard
library or build it more directly into the language.