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

Re: Why would anyone want opacity?

> Jeff Dalton wrote concerning the prevalence of
> representation-dependent code:
> > Do you have, like, statistics?
> No, but I have lots and lots of anecdotal evidence.  Most people
> who have supervised a reasonably large multi-person project have
> similar stories to tell.

Well, the immediate issue wasn't the prevalence of representation-
dependent code; it was how often such code was written by accident.
I have seen a fair amount of annoyingly representation-dependent
code, but very little (if any) of it was written by accident, so
far as I could tell.  Perhaps my experience is unusual.  I don't

In any case, the rest of your reply clarifies things immensely:

> > Your map instead of map-set looks like a plausible source of
> > accidental errors, but how often are the words so similar?
> It isn't the similarity of the  words that causes the problem.
> The problem comes from forgetting whether you're an implementor
> of the ADT (in which case it's ok to depend upon the representation)
> or a client of the ADT.  This is a conceptual problem that most
> inexperienced programmers seem to have, particularly when they
> spend their morning implementing the ADT and their afternoon
> writing client code (and switching back and forth between the
> two to fix bugs).
> It's a special case of the well-documented problem of switching
> between two cognitive contexts.  It's not a lexical problem at all.

There are often cues to help the programmer out.  For instance,
the ADT implementation might be in one file and the client code
in another.  Or, when using an object system, the implementator
might (typically) be defining methods while the client is just 
calling the generic functions.

In any case, I'm not sure how much this has to do with records.
If the records are opaque, then no one gets to look inside.
It's not like an ADT implementation gets to look inside while
client code doesn't.  And if the records aren't opaque, then
the cases when anyone would use the primitive "get the nth
slot" operation (or whatever the "abstraction-breaking"
primitive is) are fairly rare.  It's not as if someone who
was implementing an ADT would use it all the time.

Or consider SET-MAP vs MAP.  If the record mechanism defines new
record types, disjoint from each other and from other types (even 
if records aren't opaque), then MAP would never have worked.  It's
only if the initial implementation used lists that MAP would have
worked (by accident), and that can happen no matter what we decide
about records.

-- jd