sarge@sham.Berkeley.EDU (Steven Sargent) (03/22/88)
> (Digression: I wish C++'s type system had a good way to express the > concept of "lvalue". Reference types don't quite do it. I'd love to see > discussion of the subtleties of this, under another subject heading.) I had an application for just such a thing: an "undo log" manager that maintained a file window. Clients of the class would make array references e.g., undo_log[i]; these would map back to the window, "faulting in" a different block when necessary -- kind of a stdio but with built-in random access. "Alas, it does not function": in order to write back dirty blocks, I had to know that they had been modified; a scheme that returned references to elements couldn't do this, because there's no way to tell a reading reference from a writing reference. (And not even a truth-in-advertising requirement on =, =+, et al... no need for them to do assignment or anything remotely analogous.) > > Another problem is that "." functions are often proposed as a way of > getting lvalue pseudo-members. A Trellis/Owl paper (in OOPSLA '86?) > gives as an example a thermostat object whose setting is changed by > assigning to the "Celsius" field or to the "Fahrenheit" field. The value > assigned is treated as a temperature from the appropriate scale. One (or > both) is a pseudo-member that scales the given temperature and sets other > members. This won't work in C++, because assignment is an operator that is > evaluated after its left operand. I haven't decided whether lvalue > pseudo-members are good things or not. We can argue about that, too. Imagine a hardware interface that has two sets of addresses. Use range [0,m) to read its device status registers; use locations [n,n+m) to write to them. (I've met stranger beasties!) Grind your teeth for awhile as you program this Gedanken 2000 board, muttering imprecations against its designers. I think the pseudo-member idea is entirely analogous. Now this goes entirely against my truth-in-advertising argument above (so I flip-flop... don't look at me like I shot your dog), but I'd guess the most orthogonal solution is to split out references into reading and writing references, with some form of communication to the implementing function (or perhaps separate implementing functions). The use of such things would, alas, be entirely conventional -- I don't see a good way to prevent a putative writer from not writing -- but isn't it a goal of programming languages to support user conventions? > > Glen Ditchfield watmath!violet!gjditchfield > Dept of Computer Science, U of Waterloo (519) 885-1211 x6658 > Waterloo, Ontario, Canada Office: MC 2006 > If you grab the bull by the horns, you at least confuse him -- R.A.Heinlein Steven Sargent Experimental Computing Facility (XCF) University of California, Berkeley --- ARPA Internet: sarge@scam.berkeley.edu TPCnet: {all Christendom}!ucbvax!scam!sarge