Revised SRFI-76 (R6RS Records) draft
Donovan Kolbly
(02 Jan 2006 14:54 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft
Taylor Campbell
(02 Jan 2006 16:28 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft
Michael Sperber
(03 Jan 2006 17:04 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft
Taylor Campbell
(03 Jan 2006 21:00 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft
Michael Sperber
(04 Jan 2006 18:19 UTC)
|
Need to avoid breaking abstractions? Then *DON'T*. bear (10 Jan 2006 18:12 UTC)
|
Re: Revised SRFI-76 (R6RS Records) draft
Per Bothner
(03 Jan 2006 21:05 UTC)
|
Need to avoid breaking abstractions? Then *DON'T*. bear 10 Jan 2006 18:12 UTC
On Wed, 4 Jan 2006, Michael Sperber wrote: > > Without opacity and with reflection, a client who gets its hands on a > record can get at its fields, thus breaking the abstractions provided > by the maker of that record. And this is as it should be. The need for opacity reminds me of the old story of the fool and the doctor. Remember the old saw about a patient who comes in, and while the doctor is watching, wrenches his arm out of its socket, complaining, "Doctor, doctor, it hurts when I do this!" And the doctor's calm, reasonable response: "Don't do that." We are faced with much the same situation in the desire for opacity. It has become the vogue for "doctors" (language designers) to devise elaborate trusses to prevent people from intentionally wrenching their arms out of the socket, but these are, in some sense, silly since reasonable and intelligent people do no such thing except in the most extreme circumstances (say to escape a deadly trap, or facilitate foreign-function interface) and in that case ought not be prevented. If programmers do not want to break abstractions, then the mere ability to break abstractions is not a problem. And if they do want to break abstractions, I presume that if they are intelligent people then they have good reasons for doing so, and in that case the language features that inhibit it are actively harmful. Bear