[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why would anyone want opacity?
> It appears to me that Jeff Dalton thought I was talking about
> some horribly low-level abstraction-breaking facility that
> would allow a client to use something analogous to LIST-REF
> on arbitrary records.
>
> I was actually talking about the problem of information about
> the representations of objects leaking out from the module
> that implements them.
The issue here, I thought, was why anyone would want records to be
opaque. It might extend to opacity in general. Anyway, so far as I
could tell, the difference between the two cases that have been the
main subject of discussion in this and related threads (opaque records,
non-opaque ones) is, in the end, that non-opaque records could be
accessed by some "horribly low-level abstraction-breaking facility".
Hence my use of an example of such a facility.
I thought it was pretty clear that Will Clinger was talking about
the problem of information about the representations of objects
leaking out from the module that implements them. But that's
rather abstract, and I want to see what it amounts to when it
comes to possible ways of adding records to Scheme.
> In Scheme the analogue of the syntactic notations in C++ is
> the use of a representation-dependent special form such as
> CASE or the use of a representation-dependent predefined
> procedure such as EQ?, EQV?, or EQUAL?. These things are
> legitimate for use with appropriate built-in types such as
> symbols, but it is a bug to use them on any program-defined
> ADTs outside of the module that implements the ADT.
Ok. But why can't that problem be handled, adequately well, by
records that are not lists, vectors, etc, and (perhaps) not of the
same type as other records? Just say such records are not valid
arguments to any representation-dependent predefined procedures they
shouldn't be arguments to. (I happen to think EQ? and EQV? should work
on all objects, that records should be objects, and that if that stops
us from having true abstract types it's a price worth paying -- but
that's something that can be discussed separately.)
What does the extra benefit of having opaque records amount to?
-- jd