rick@tetrauk.UUCP (Rick Jones) (06/07/91)
In article <131263@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes: >In article <1177@tetrauk.UUCP> I wrote: > ... >>In fact I would suggest that a system in which large objects are used is best >>handled using reference semantics, otherwise there will be a lot of >>inefficiencies elsewhere resulting from copying. The programmer must of course >>be aware of this, and use "clone" operations where required. > >I guess I did presume it was obvious that the strange side effects which >result from the aliasing inherent in general reference semantics violated >the comprehensibility requirement for reusable software. > >As it turns out, referencs semantics are fine -- provided you only allow >_one_ reference to each object. (With this constraint, you effectively >have value semantics, of course.) Now the problem, rephrased in these >terms, is that our small object bias leads us to design classes with operations >like Top which create multiple references to the same object. One of >the challenges of object oriented programming is still to design classes >so that excess copying can be avoided or (if you insist on reference >semantics) so that multiple references can be avoided. I strongly disagree that reference semantics are inherently a bad thing. There are a large number of real problems which require multiple references in order to produce a reasonable soultion. The general scenario is where a run-time object represents the state of some part of the system, and may be updated by asynchronous events. If various other objects' behaviour is dependent on this state, then they all need to refer to the common object. If only single references are allowed, then the events need to propagate their effects to all relevant objects. This creates far more complexity and difficulty than the basic concept of multiple reference. I suspect many people may be wary of using references as a result of experiences with pointers in C, but C's pointers are open to far more abuse than pure references. I have found that one of the benefits of Eiffel is that it makes a system with extensive use of references comprehensible and maneagable (garbage collection is one of the essential components of this). Although good OO design and programming systems can emphasise abstract concepts and isolate a programmer from implementation details, it should never attempt to hide the distinction between value and reference. This is something that both the designer and programmer must understand, and use both to best advantage. -- Rick Jones, Tetra Ltd. Maidenhead, Berks, UK rick@tetrauk.uucp Any fool can provide a solution - the problem is to understand the problem
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/08/91)
In article <1178@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >> ... Now the problem, rephrased in these terms, >>is that our small object bias leads us to design classes with operations >>like Top which create multiple references to the same object. One of >>the challenges of object oriented programming is still to design classes >>so that excess copying can be avoided or (if you insist on reference >>semantics) so that multiple references can be avoided. >I strongly disagree that reference semantics are inherently a bad thing. There >are a large number of real problems which require multiple references in order >to produce a reasonable soultion. ... >Although good OO design and programming systems can emphasise abstract concepts >and isolate a programmer from implementation details, it should never attempt >to hide the distinction between value and reference. This is something that >both the designer and programmer must understand, and use both to best >advantage. The issue is not that reference semantics are inherently a bad thing any more than that dynamite is an inherently bad thing. Neither, however, is intended for every day or casual use. The problem is that building classes which force clients to use operations like Top that just return a reference to a stack entry is rather like building hardware stores which supply customers with sticks of dynamite whenever they ask for something with which to remove a tree from their lawns. If clients are careful or lucky they achieve their objectives. If not, you're left with a bloody mess. There's no problem with using multireference objects (or dynamite) and passing out references with a Top operation, if you like. The problem is with making this the normal rather than the exceptional way of doing business. -- /Bill
rick@tetrauk.UUCP (Rick Jones) (06/10/91)
In article <131691@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes: |>> ... Now the problem, rephrased in these terms, |>>is that our small object bias leads us to design classes with operations |>>like Top which create multiple references to the same object. One of |>>the challenges of object oriented programming is still to design classes |>>so that excess copying can be avoided or (if you insist on reference |>>semantics) so that multiple references can be avoided. | |In article <1178@tetrauk.UUCP> I wrote: | |>I strongly disagree that reference semantics are inherently a bad thing. There |>are a large number of real problems which require multiple references in order |>to produce a reasonable soultion. | ... |>Although good OO design and programming systems can emphasise abstract concepts |>and isolate a programmer from implementation details, it should never attempt |>to hide the distinction between value and reference. This is something that |>both the designer and programmer must understand, and use both to best |>advantage. | |Bill Ogden replied: | |The issue is not that reference semantics are inherently a bad thing any |more than that dynamite is an inherently bad thing. Neither, however, is |intended for every day or casual use. The problem is that building classes ^^^^^^^^^ ^^^^^^ - see below |which force clients to use operations like Top that just return a reference |to a stack entry is rather like building hardware stores which supply |customers with sticks of dynamite whenever they ask for something with |which to remove a tree from their lawns. If clients are careful or lucky |they achieve their objectives. If not, you're left with a bloody mess. | |There's no problem with using multireference objects (or dynamite) and |passing out references with a Top operation, if you like. The problem |is with making this the normal rather than the exceptional way of |doing business. We clearly have a fundamental disagreement. I would be interested to hear if you can quote any case histories to support your view - i.e. where programmers have implemented a design in a language where reference is the default (and presumably therefore well supported), and screwed up as a result. I confess that I can't do likewise for my own point of view, since our use of Eiffel is currently confined to a small team, where we are building a toolkit. I have not found Eiffel's default reference semantics create any unpleasant problems personally, but perhaps that is because I am particularly aware of what is going on. I am genuinely interested in this issue, since at some point our toolkit is going to be in "everyday use" by less experienced programmers (although I don't think any proper software project should ever treat programming as "casual"). Am I heading for trouble? Pointers in C do cause problems, and we have the experience of that, but it is very easy to make a lot of mistakes in C with pointers because the language doesn't help you handle them properly. References in an OOPL are a whole different issue. What about Smalltalk? I only have a very limited knowledge of it, but does it not generally employ reference semantics? Of all languages, its object model is probably least obvious, so if reference semantics are going to lead to problems, I would expect it to be apparent in Smalltalk. Can any experienced Smalltalk users comment on this (I am widening this thread to comp.object for this reason). -- Rick Jones, Tetra Ltd. Maidenhead, Berks, UK rick@tetrauk.uucp Chairman, NICE (Non-profit International Consortium for Eiffel) Any fool can provide a solution - the problem is to understand the problem
johnson@cs.uiuc.EDU (Ralph Johnson) (06/11/91)
As a longtime Smalltalk programmer, I don't see how its use of reference semantics causes problems. Reference semantics and copy semantics are not just different styles of programming, they are different *semantics*. They mean different things. Sometimes a programmer wants to have stateless values, and sometimes a programmer wants to have objects with state. A language should support both. I've tried functional programming in C, and it is hard, mostly because of the lack of garbage collection. Programming with immutable objects and without side effects is not hard in Smalltalk. I usually partition a system into the "stateless" parts and the "stateful" parts. I usually consider it an improvement when I can convert mutable objects to immutable objects. That doesn't happen often, because it is usually pretty obvious which is which. I can understand how someone who dosen't understand reference semantics (or copy semantics, for that matter) will have problems when they first start to use it. People have trouble with nearly anything when they first start to use it, including procedures, side effects, recursion, inheritance: in short, programming! Improper use of references can certainly cause problems, but improper use of anything can cause problems. I shudder when I see someone passing a "store" in a functional language to simulate reference semantics. Reference semantics makes many programs simpler.
kentb@argosy.UUCP (Kent Beck) (06/11/91)
After a year and a half working on a project containing 50K non-comment source lines of Smalltalk I just got my first defect that was a result of improper aliasing. I marked it at the time because I could not remember seeing many such bugs in code I have worked on previously. Kent Beck
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/12/91)
In article <1181@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: ... >Pointers in C do cause problems, and we have the experience of that, (Yes, and the safety problems with nitroglycerin made dynamite a welcome discovery too. :-) > but it is >very easy to make a lot of mistakes in C with pointers because the language >doesn't help you handle them properly. References in an OOPL are a whole >different issue. Somehow I'm getting this deja vu sensation that we're back in the late 60's discussing Go To's. One side is saying that Go To's (object references) have an excessively complex semantics which can easily lead to programming errors. On the other side, a few people concede that computed Go To's (C pointers) might be a problem. However, most argue that since the jump instruction (pointer) is essential for low level programming (basic data structuring), it must be retained, perhaps slightly syntactically sugared, as a central feature of high level programming structuring (reusable object design). -- /Bill
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/12/91)
In article <1991Jun10.215822.28034@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: ... >Improper use of references can certainly cause problems, but >improper use of anything can cause problems. Improper use of GoTo's can certainly cause problems also, but we don't use them much any more. We observed that there was a problem and that there were efficient alternatives, and we changed our ways. -- /Bill
johnson@cs.uiuc.EDU (Ralph Johnson) (06/12/91)
In article <133169@tut.cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes: |> In article <1991Jun10.215822.28034@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: |> ... |> >Improper use of references can certainly cause problems, but |> >improper use of anything can cause problems. |> |> Improper use of GoTo's can certainly cause problems also, but we don't |> use them much any more. We observed that there was a problem and that |> there were efficient alternatives, and we changed our ways. |> |> -- |> |> /Bill Bill, this is an annoying message. I carefully stated that reference semantics were often the RIGHT way to think about a problem and to specify it. You seem to have completely ignored the whole point of my message, so why bother to quote it? Perhaps C pointers are like go-tos, but object references are not. If you want to model a world with state then object references make programs clearer and easier to understand. In my opinion, the inventions of the functional programming language community to compensate are confusing and are unlikely to make programs easier to understand. If you don't have references in your language then you will be forced to simulate them. Consider a user interface system. It is natural to model buttons and menus as objects with state. Without references you will end up with "button-id" values and a set of "pressed-buttons" that tells you whether a button is pressed. There will be a function "clients" that indicates the program entities that should be notified when the button is pushed. Now you end up passing around button-ids and checking whether it is in the pressed-buttons set and notifying its clients. This is no different from a reference. However, lack of references has caused all sorts of data to be distributed throughout the system instead of being encapsulated and hidden. I claim that this kind of a design is much worse than the natural design with references. Ralph Johnson
sakkinen@jyu.fi (Markku Sakkinen) (06/12/91)
In article <133154@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes: >In article <1181@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: > ... >>Pointers in C do cause problems, and we have the experience of that, > >(Yes, and the safety problems with nitroglycerin made dynamite a welcome >discovery too. :-) > >> but it is >>very easy to make a lot of mistakes in C with pointers because the language >>doesn't help you handle them properly. References in an OOPL are a whole >>different issue. > >Somehow I'm getting this deja vu sensation that we're back in the late 60's >discussing Go To's. One side is saying that Go To's (object references) have >an excessively complex semantics which can easily lead to programming errors. >On the other side, a few people concede that computed Go To's (C pointers) >might be a problem. However, most argue that since the jump instruction >(pointer) is essential for low level programming (basic data structuring), >it must be retained, perhaps slightly syntactically sugared, as a central >feature of high level programming structuring (reusable object design). Analogies and parables are often useful, but often also dangerous: keep in mind that they can only suggest something, never prove it. I think that the need to share some objects is much more fundamental for object modelling than is the need to jump for imperative programming. The (visible) use of references should be restricted to a minimum, but accepted without remorse whenever it is necessary. ---------------------------------------------------------------------- "All similarities with real persons and events are purely accidental." official disclaimer of news agency New China Markku Sakkinen (sakkinen@jytko.jyu.fi) SAKKINEN@FINJYU.bitnet (alternative network address) Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland ----------------------------------------------------------------------
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/13/91)
In article <1991Jun11.223305.16439@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: |>>Improper use of references can certainly cause problems, but |>>improper use of anything can cause problems. |> Improper use of GoTo's can certainly cause problems also, but we don't |> use them much any more. We observed that there was a problem and that |> there were efficient alternatives, and we changed our ways. >Bill, this is an annoying message. I carefully stated that reference >semantics were often the RIGHT way to think about a problem and to >specify it. You seem to have completely ignored the whole point of >my message, so why bother to quote it? My intent was certainly not to annoy but rather (in the Socratic tradition of such dialogues on these newsgroups) to try to make a point as clearly as possible. The point was that what is initially considered to be a relatively minor negative feature of a solution mechanism can prove to be its undoing. >Perhaps C pointers are like go-tos, but object references are not. C pointers are surely a more `interesting' mechanism, perhaps engendering a level of excitement in programming more comparable to that produced by the jump instruction in assembly languages. Be that as it may, it still seems that an object which is the target of multiple references is completely analogous to a label which is the target of multiple GoTo's. >If you want to model a world with state then object references make >programs clearer and easier to understand. In my opinion, the inventions >of the functional programming language community to compensate are >confusing and are unlikely to make programs easier to understand. I sense that a _false alternative_ may be intruding into the discussion here. The options are not either an object oriented approach with multi- reference semantics or a pure functional language approach; there is a whole spectrum of other possibilities. >If you don't have references in your language then you will be forced >to simulate them. I don't think anyone would propose banning references at this stage in history. The issue was whether their routine use should be encouraged. > Consider a user interface system. It is natural to ... [Sketch deleted] Sounds interesting. Could you elaborate a simple example in sufficient detail to make it clear what the basis for the claim that references are essential for a well encapsulated design is. (Email would be fine, if the smallest examples are too messy for viewing by a general audience.) -- /Bill
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/13/91)
In article <1991Jun12.072557.7282@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes: ... >Analogies and parables are often useful, but often also dangerous: >keep in mind that they can only suggest something, never prove it. >I think that the need to share some objects is much more fundamental >for object modelling than is the need to jump for imperative programming. >The (visible) use of references should be restricted to a minimum, >but accepted without remorse whenever it is necessary. It's true that analogies only suggest, but don't prove. In this case, the analogy suggests strongly that we examine very carefully whether the visible use of references is really that central to object oriented design. A good example or two showing where references are fundamentally necessary could perhaps expose the deficiencies of the proposed [dangerous?] analogy. -- /Bill
diamond@jit533.swstokyo.dec.com (Norman Diamond) (06/13/91)
In article <1991Jun12.072557.7282@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes: >In article <133154@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes: >>In article <1181@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >>>Pointers in C do cause problems, and we have the experience of that, >>> but it is >>>very easy to make a lot of mistakes in C with pointers because the language >>>doesn't help you handle them properly. References in an OOPL are a whole >>>different issue. >> >>Somehow I'm getting this deja vu sensation that we're back in the late 60's >>discussing Go To's. One side is saying that Go To's (object references) have >>an excessively complex semantics which can easily lead to programming errors. > >I think that the need to share some objects is much more fundamental >for object modelling than is the need to jump for imperative programming. >The (visible) use of references should be restricted to a minimum, >but accepted without remorse whenever it is necessary. I agree with that conclusion, but think that the reasoning and application are backwards. Sharing and aliasing are sometimes necessary and should be kept to a minimum, yes. I think the sharing and aliasing should be visible, so that readers will know what to expect. The invisible aliasing generated by reference semantics is worse than a label that is a target of multiple gotos. An object gets changed when the user didn't expect it, and has to do a lot of tracing to find out where.... Part of the problem with C pointers is that they are overused and abused as a result of C's treatment of arrays. (A garbage collection in C can be declared with [].) A fairer comparison would be Pascal-style pointers (or even PL/I-style pointers) vs. the invisible sharing generated by reference semantics. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it. Permission is granted to feel this signature, but not to look at it.
sakkinen@jyu.fi (Markku Sakkinen) (06/14/91)
I am cross-posting this article and the following one to comp.object because the question is interesting not only to the Eiffel community. In article <133644@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes: >In article <1991Jun12.072557.7282@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes: >> ... >It's true that analogies only suggest, but don't prove. In this case, >the analogy suggests strongly that we examine very carefully whether >the visible use of references is really that central to object oriented >design. A good example or two showing where references are fundamentally >necessary could perhaps expose the deficiencies of the proposed [dangerous?] >analogy. class person export ... inherit ... feature mother: person; heart: human_heart; ... end It is essential that several persons can have the same mother. On the opposite, a heart cannot be shared. I consider it a deficiency of languages such as Lisp, Smalltalk, and Eiffel that this important semantic difference cannot be expressed; and the main reason is that references are used for "everything". (Arrrgh: I already wrote and submitted something like this yesterday, but some testing of the news system here caused all articles to get lost.) ---------------------------------------------------------------------- "All similarities with real persons and events are purely accidental." official disclaimer of news agency New China Markku Sakkinen (sakkinen@jytko.jyu.fi) SAKKINEN@FINJYU.bitnet (alternative network address) Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland ----------------------------------------------------------------------
sakkinen@jyu.fi (Markku Sakkinen) (06/14/91)
In article <1991Jun13.074318.337@tkou02.enet.dec.com> diamond@jit533.enet@tkou02.enet.dec.com (Norman Diamond) writes: >In article <1991Jun12.072557.7282@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes: >> ... >>I think that the need to share some objects is much more fundamental >>for object modelling than is the need to jump for imperative programming. >>The (visible) use of references should be restricted to a minimum, >>but accepted without remorse whenever it is necessary. > >I agree with that conclusion, but think that the reasoning and application >are backwards. Sharing and aliasing are sometimes necessary and should be >kept to a minimum, yes. I think the sharing and aliasing should be visible, >so that readers will know what to expect. The invisible aliasing generated >by reference semantics is worse than a label that is a target of multiple >gotos. An object gets changed when the user didn't expect it, and has to >do a lot of tracing to find out where.... Incidentally, I think similarly. I would have said: "I share your opinions", but of course my opinions do not change automatically if you change yours :-) What I meant by 'visible' was 'affecting semantics': it does not harm programmers if references are used only as an implementation device, which can be efficient for large objects. >Part of the problem with C pointers is that they are overused and abused >as a result of C's treatment of arrays. (A garbage collection in C can be >declared with [].) A fairer comparison would be Pascal-style pointers (or >even PL/I-style pointers) vs. the invisible sharing generated by reference >semantics. We agree even here. Pointer arithmetic has no place in a language that wants to be considered high-level. Also the fact that pointers in C and C++ can be made to point at any object of their referent type (as opposed to the restrictions of Pascal and Ada) makes them harder to manage, although it offers some advantages, too. To make my position clear: I regard it as a _good_ feature of C and C++ that 'widget' and 'pointer to widget', i.e. '*widget', are clearly distinct types. (Arrrgh: I already wrote and submitted something like this yesterday, but some testing of the news system here caused all articles to get lost.) ---------------------------------------------------------------------- "All similarities with real persons and events are purely accidental." official disclaimer of news agency New China Markku Sakkinen (sakkinen@jytko.jyu.fi) SAKKINEN@FINJYU.bitnet (alternative network address) Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland ----------------------------------------------------------------------
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/15/91)
In article <1991Jun14.073249.1469@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes: ... >> A good example or two showing where references are fundamentally >>necessary could perhaps expose the deficiencies of the proposed [dangerous?] >>analogy. >class person > export ... inherit ... > feature > mother: person; > heart: human_heart; > ... end >It is essential that several persons can have the same mother. >On the opposite, a heart cannot be shared. I consider it a deficiency >of languages such as Lisp, Smalltalk, and Eiffel that this important >semantic difference cannot be expressed; and the main reason is that >references are used for "everything". An amusing note on this example is that Markku's earlier warning about how dubious analogies might lead our thinking astray is applicable to so many of the prototypical examples used to develop the designs for various object oriented programming systems. In this case, the intended analogy is to a familiar world filled with people having mothers and hearts. What one would want to do (e.g. what operations) in the imperative world of computing which is related to the this everyday world is, of course, central to deciding how the computational objects should be structured but is left unspecified (as is traditional in such examples). Depending upon what we're really supposed to do in this example, some sort of structure which supports finding mothers efficiently is probably needed. However,if there are going to be operations on individuals that modify their mothers, then it's not clear that we're looking at the cleanest possible design here. Without more detail, the example just doesn't make a compelling case for using reference semantics routinely. -- /Bill
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/15/91)
In article <133169@tut.cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes: > In article <1991Jun10.215822.28034@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: > ... > >Improper use of references can certainly cause problems, but > >improper use of anything can cause problems. > Improper use of GoTo's can certainly cause problems also, but we don't > use them much any more. We observed that there was a problem and that > there were efficient alternatives, and we changed our ways. I suggest that this is a bogus argument. I often use functional languages that haven't even got assignment, let alone something with 'goto' syntax. But they _do_ exploit ``tail call optimisation'', so it is just as accurate to look at a network of function definitions and say "those are labels, those calls are gotos". That's what they compile into, after all. Any semantic problems that were ever associated with gotos remain in full force when you use procedure calls. There are two kinds of problems with pointers: allocation status mistakes and unexpected consequences of sharing. Allocation status mistakes we can easily get rid of: if you write programs in CLOS or SCOOPS or Smalltalk or ... then you simply can't express the mistakes. There are good arguments for saying that sharing ought to be explicitly marked, so that structured values which weren't intended to be shared don't have unexpected consequences, but if sharing isn't allowed at all, then your language is a pure functional language in all but syntax and has no `objects'. When you are modelling a situation in which an entity can change state, and you want more than one other entity to be able to refer to the changing entity, you have all the problems of sharing whether you use pointers, references, object IDs, indexes into an array, or artificial telepathy. -- Q: What should I know about quicksort? A: That it is *slow*. Q: When should I use it? A: When you have only 256 words of main storage.
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/18/91)
In article <6351@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: ... |>>Improper use of references can certainly cause problems, but |>>improper use of anything can cause problems. |> Improper use of GoTo's can certainly cause problems also, but we don't |> use them much any more. ... >I suggest that this is a bogus argument. I often use functional languages >that haven't even got assignment, let alone something with 'goto' syntax. >But they _do_ exploit ``tail call optimisation'', so it is just as >accurate to look at a network of function definitions and say "those are >labels, those calls are gotos". That's what they compile into, after all. >Any semantic problems that were ever associated with gotos remain in full >force when you use procedure calls. (I assume this isn't a call for reviving the GoTo :-) Procedures which have explicit parameters and don't side-effect global variables are semantically simpler than GoTo's and Labels. Side-effecting procedures probably don't offer much advantage over GoTo's. Now the fact that a compiler hides the low-level jump statement and only uses it in safe ways is precisely the point of a good high-level abstraction. The user of higher level control constructs really lives in a semantically simpler and safer world. > ... There are good >arguments for saying that sharing ought to be explicitly marked, so that >structured values which weren't intended to be shared don't have unexpected >consequences, but if sharing isn't allowed at all, then your language is a >pure functional language in all but syntax and has no `objects'. I certainly agree that sharing should be explicitly indicated; the above remarks were part of a discussion about the dangers of the routine unflaged sharing which is implicit in reference semantics. However, I believe you've drawn a false dichotomy between languages with sharing and pure functional languages. There's not much sharing in a language like say FORTRAN or BASIC, but I really doubt the functional language camp would claim such languages either. -- /Bill
Kai_Henningsen@ms.maus.de (Kai Henningsen) (06/18/91)
William F Ogden ogden @ seal.cis.ohio-state.edu schrieb am Di 11.06.1991, 19:15 WF>Somehow I'm getting this deja vu sensation that we're back in the late 60's WF>discussing Go To's. One side is saying that Go To's (object references) have [...] Hey, maybe the answer is the same: retain GOTO (object references) for those cases that really need them/are better understandable with them/whatever, but consider that the exceptional case and use "higher level" constructions like loops (copy-on-write-semantics? :-)) whenever possible, thus even allowing the compiler to try better optimizations ... and of course we can still use good old sequential programming (value semantics) for those trivial cases that make the dull 90% part of the work (like good ol' integer math) ... -- Kai Henningsen Internet: kh@ms.maus.de Muenster UUCP: any_backbone_that_knows_domains!ms.maus.de!kh Germany Fido: kh%maus ms, 2:242/2.6 or Kai Henningsen, 2:242/2.244
Kai_Henningsen@ms.maus.de (Kai Henningsen) (06/18/91)
Markku Sakkinen sakkinen%jyu.fi @ SUB schrieb am Mi 12.06.1991, 07:25 MS>Analogies and parables are often useful, but often also dangerous: MS>keep in mind that they can only suggest something, never prove it. MS>I think that the need to share some objects is much more fundamental MS>for object modelling than is the need to jump for imperative programming. I don't think so. Jumping around IS fundamental for imperative programming. What is NOT fundamental is using the GOTO construct to do it, and nowadays we prefer all sorts of FOR, WHILE, IF, CASE and whatever constructions to do just the same jumping around, albeit in a much more controlled fashion. The same might be true for reference semantics: while the raw form is dangerous, there might be more controlled forms that are not. We might already know about some, and not about others; but I think that idea is worth pursuing. So, the question is: what do we *really* want to accomplish with reference semantics? Could we devise one or more models with not-as-general semantics that do exactly that in a controlled form? Think of GOTO vs. FOR, WHILE, IF-THEN-ELSE. -- Kai Henningsen Internet: kh@ms.maus.de Muenster UUCP: any_backbone_that_knows_domains!ms.maus.de!kh Germany Fido: kh%maus ms, 2:242/2.6 or Kai Henningsen, 2:242/2.244
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/18/91)
In article <135300@tut.cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes: > In article <6351@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > >Any semantic problems that were ever associated with gotos remain in full > >force when you use procedure calls. > (I assume this isn't a call for reviving the GoTo :-) I don't see why you're assuming anything. Read my lips: Goto is not dead. > Procedures which > have explicit parameters and don't side-effect global variables are > semantically simpler than GoTo's and Labels. I'm sorry, but this turns out not to be the case. Let me repeat the sentence above: ANY semantic problems that were ever associated with gotos [insertion: gotos in fact have *very* simple proof rules] remain in FULL force when you use procedure calls [insertion: in fact proof rules for procedure calls are MORE complex than proof rules for labels and gotos.] This is not a theoretical abstraction. I have noticed, IN PRACTICE, that when reading a couple of hundred lines of functional code (which I like, make no mistake) I get the same sensation as when I used to read assembly code. There is one great big mass of spaghetti, and unsnarling references to functions (when every second line defines a new function) is not one iota easier than unsnarling references to labels. > Now the fact that a compiler hides the low-level jump statement and only > uses it in safe ways is precisely the point of a good high-level abstraction. You have missed the point completely. The point is that the difficulty with gotos was not that they were theoretically unclean (quite the opposite! I repeat, the proof rules for (local) goto are SIMPLER than the proof rules for procedure call) but that you had to do a lot of moving your finger around a listing and mumbling to yourself to figure out what came from where. The hardware jump was never the problem, it was figuring out what the connection between a particular jump and a particular label MEANT. As soon as you have thousands of little procedures, you get exactly the same kind of problems grasping the interconnections. > The user of higher level control constructs really lives in a semantically > simpler and safer world. This turns out not to be the case. *Anything* you could do with labels can be done IN THE SAME WAY (I mean preserving apparent structure, size of output of transliteration process is a linear function of size of input) using function calls. This has been known since the early 60s, where have you been? > There's not much sharing in a language like say FORTRAN or BASIC, > but I really doubt the functional language camp would claim such languages > either. There is a h**l of a lot of sharing in Fortran. It's the major factor inhibiting the parallelisation that the scientific computing people would like to get. Where is the sharing? Destructive assignment to array elements. Think pointer : set of objects of base type :: integer : array There was an experiment reported about 4 or 5 years ago in one of the parallel programming conferences which studied this very matter. The best parallel speedups on the codes studied were around 15; when the synchornisation bottleneck due to this sharing was eliminated the speedups were as much as 700. I basically made the same point twice, and it was completely missed twice. Just because it doesn't LOOK like a goto doesn't mean that it doesn't ACT like a goto and have the PROBLEMS of a goto. Just because it doesn't LOOK like a pointer doesn't mean that it doesn't ACT like a pointer and have the PROBLEMS of a pointer. As for whether the functional community would claim Fortran or Basic, they *were* credited with Euclid (very Pascalish, but no aliasing). And the Boyer-Moore theorem prover was used to verify some Fortran examples by transliterating them into pure Lisp... To get back to OOP: the problem is not sharing, but _assignment. Objects belonging to a class that cannot be modified could be shared without anyone noticing. -- Q: What should I know about quicksort? A: That it is *slow*. Q: When should I use it? A: When you have only 256 words of main storage.
phil@abccam.abcl.co.uk (Phillip Yelland) (06/18/91)
I hope you'll forgive me if I barge in this thread, but I thought I'd throw
in my h'a'p'eth worth (two cents' worth---substitute currency as
appropriate) and a plug. I've recently defended (successfully, deo gratias)
a thesis which examines the implications of the use of references in OOL's
on their formal semantics. I wouldn't insist my findings were conclusive,
but the models I came up with did rather undermine the naive conception of
objects in such languages as neat, encapsulated parcels of state with a
finely circumscribed interface. An abbreviated summary of part of the thesis
appears in the recently-published Springer LNCS 489
("Foundations of Object-Oriented Languages"---de Bakker, de Roever,
Rozenberg). I'd be happy to provide copies of either of the above,
though I'm afraid I'll need postage as my
present employer is unlikely to subsidize such activity.
I'm particularly intrigued by Kent Beck's insistence (in an earlier message)
that aliasing bugs occur in his Smalltalk code with relative infrequency.
Could he enlighten us as to how onery/hard-to-locate he actually finds such
bugs? We've recently signed off a 50K-line Smalltalk project; while they
weren't all that common, we did experience aliasing bugs that were both very
well hidden and the cause of the most bizzare consequences (windows crawling
spontaneously around the screen, etc.). (I'd not like to insist, of course,
that our Smalltalk skills are comparable to Kent's.)
--Phillip Yelland
P.S. I'm trying to locate one William Cook, late of HP Labs Palo Alto,
who---it is commonly held---has disappeared into the maw of Apple research.
Could anyone provide any pointers (:-)?ian@syacus.acus.oz.au (Ian Joyner) (06/19/91)
ogden@seal.cis.ohio-state.edu (William F Ogden) writes: >It's true that analogies only suggest, but don't prove. In this case, >the analogy suggests strongly that we examine very carefully whether >the visible use of references is really that central to object oriented >design. A good example or two showing where references are fundamentally >necessary could perhaps expose the deficiencies of the proposed [dangerous?] >analogy. Maybe I'm missing something, but it seems to me that references are a fundamental thing in the real world. Take networking and databases, where shared information is what the customer wants. The user may want fast access to some information, and therefore have their own copy, or alias. But this has the danger that their information gets out of date. If slightly out of date information is acceptable then this is OK. If it is not acceptable, then the user must always access the original by means of a reference. As object oriented programming reflects the real world, it seems that references will be inevitable. However, if we did not share data like this, then all the research into concurrency would be unnecessary. I think that in the abstract sense, that communications references (addresses) and OO references are the same thing. Conceptually, they are not C pointers, although underneath they may be implemented the same, just as conditionals, loops, etc are implemented the same underneath as gotos, ie jumps. Similarly in the database world, there is a lot of effort to keep a database consistent. Again this is only a problem because it is a common requirement to share common data. I suspect this is actually what makes computers so useful. If it were not a requirement, we may as well not have data bases or data communications at all. But then my life would be much simpler! -- Ian Joyner Australian Centre for Unisys Software 61-2-390 1328 ian@syacus.oz -- Ian Joyner ACSNet: ian@syacus.oz ACUS (Australian Centre for Unisys Software) DNS: ian@syacus.oz.au Tel 61-2-390 1328 Fax 61-2-390 1391 UUCP: ...uunet!munnari!syacus.oz
kers@hplb.hpl.hp.com (Chris Dollin) (06/19/91)
If I may add my views to others ... My ``normal'' language (ie the one I use by preference) is Pop11 (which for the purposes of discussion you can take to be a Lisp-like language); compound objects (sorry, things; Pop isn't OO) are references, ie, aliasing abounds. My experience is that this presents no particular problem. The occasional nasty is no worse than the occasional nasties you get from other kinds of logical errors. Sharing and object identity open up just as many idioms as they close. -- Regards, Chris ``GC's should take less than 0.1 second'' Dollin.
rick@tetrauk.UUCP (Rick Jones) (06/19/91)
>It is essential that several persons can have the same mother. >On the opposite, a heart cannot be shared. I consider it a deficiency >of languages such as Lisp, Smalltalk, and Eiffel that this important ^^^^^^ >semantic difference cannot be expressed; and the main reason is that >references are used for "everything". Sorry, Markku, you're not up to date with Eiffel. From Eiffel 2.2 onwards (that's nearly 2 years ago), a class variable can be declared as "expanded". This means it gets value semantics - i.e. every assignment is a copy. Eiffel 3 allows a _class_ to be declared as expanded, so every instance is distinct. In fact, in ISE's version of Eiffel 3, expanded objects will be _implemented_ using references, but the compiler will enforce _value_ semantics - i.e. it will guarantee no aliasing. You can do it both ways, it just happens that the default semantics are reference. I think this is quite reasonable, since I have found in practice that extensive use of reference in Eiffel does not in fact cause problems, despite the concerns raised by several people in this thread. The comments from Smalltalk users also confirm that references are not a real problem. It is not difficult to build systems where references are the norm, and to identify exceptions where alisasing must not be allowed. The use of "expanded" means these cases can be dealt with elegantly. I believe this is a better approach than taking value semantics as the norm, and then identifying cases where aliasing is either required, or can be allowed for efficiency, and using an appropriate syntax to make these the exceptions. -- Rick Jones, Tetra Ltd. Maidenhead, Berks, UK rick@tetrauk.uucp Chairman, NICE (Non-profit International Consortium for Eiffel) Any fool can provide a solution - the problem is to understand the problem
ian@syacus.acus.oz.au (Ian Joyner) (06/20/91)
ogden@seal.cis.ohio-state.edu (William F Ogden) writes: >C pointers are surely a more `interesting' mechanism, perhaps engendering >a level of excitement in programming more comparable to that produced by >the jump instruction in assembly languages. Be that as it may, it still >seems that an object which is the target of multiple references is completely >analogous to a label which is the target of multiple GoTo's. Bill, I agree with most of what you are saying, but I don't think this is the reason for considering gotos harmful. If it were then we would also ban routines being called from multiple places. There does seem to be some confusion about the banning of gotos in the general discussion. Banning gotos does not mean that the only form of flow of control allowed is sequential execution. Branches in logic are permitted, its just that they must be accomplished by the well disciplined means of conditional branches, loops and routine call/return mechanisms, (and debatably case.) These mechanisms are sufficient for all control requirements, and therefore gotos are unnecessary. The remaining place where gotos make code neater may be provided by supplying an error handling exit mechanism, other than return. However, all these mechanisms may also be simulated by the use of gotos. Perhaps in this reference question, we should not look for solutions first, but address the fundamental problem, if we can decide what that is. I think the fundamental problem is is it necessary to have multiple accesses to one common piece of data? If the answer is yes, then we need to determine the best means of fulfilling that requirement. -- Ian Joyner Australian Centre for Unisys Software 61-2-390 1328 ian@syacus.oz -- Ian Joyner ACSNet: ian@syacus.oz ACUS (Australian Centre for Unisys Software) DNS: ian@syacus.oz.au Tel 61-2-390 1328 Fax 61-2-390 1391 UUCP: ...uunet!munnari!syacus.oz
phil@abccam.abcl.co.uk (Phillip Yelland) (06/21/91)
I'd like to thank those who followed up my recent article with such cogent and reasoned responses. I'm especially grateful to Kent Beck for receiving my rather back-handed compliment in such good humour. In mitigation, I'd like to emphasize that I was attempting to make a constructive point (which I believe has also been expressed by Kai Henningsen and others); I know that Kent is a very skilled Smalltalk programmer, and it's evident from his reply that he adopts an approach to design which will bar many of the problems which aliasing might produce. By analogy with structured programming and the use of GOTO: could it be that there is a collection such strategies meet to deal with the majority of sharing requirements? Would it be worth expressing these devices explicitly in a object-oriented programming language, so as to promote disciplined engineering amongst the rest of us? --Phil P.S. To those people who expressed an interest in publications: I'll try to mail you a (latex) copy of a recent paper electronically from another site, (though I'm afraid I can't guarantee 100% success, and may need to pursue matters at greater length). I've also had a word with the great panjandrums, and my thesis should be available in due course as a technical report from the University of Cambridge Computer Laboratory (Library), New Museums Site, Pembroke St., Cambridge, Cambs. U.K. If you feel you can't possibly wait that long for the real McCoy, prod me again, and I'll be off to the Post Office to get some cost estimates. Thanks again.
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/22/91)
In article <1991Jun19.001829.28317@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes: ... >>the analogy suggests strongly that we examine very carefully whether >>the visible use of references is really that central to object oriented ^^^^^^^ >>design. A good example or two ... > ... Take networking and databases, where >shared information is what the customer wants. The user may want fast >access to some information, and therefore have their own copy, or alias. >But this has the danger that their information gets out of date. If >slightly out of date information is acceptable then this is OK. If it >is not acceptable, then the user must always access the original by >means of a reference. A database is surely a shared resourse in a system, but it's not so clear that clients should share access to subcomponents of it via visible references. Generally, if several clients are using mutually referenced information as if it were private, you're going to have big problems. It is not my impression that the database community has really resolved the problem of achieving high performance while providing safe, functionally adequate access to a database. So it's unclear that this is a good basis for an example of where visible reference semantics is the obvious solution. >As object oriented programming reflects the real world, it seems that >references will be inevitable. At the risk of getting back into those dangerous analogies, note that referencs semantics really entail multiple larger objects routinely sharing possesion of smaller objects. For very good reasons, this rarely happens in the real world. Imagine, for example, several people in a room each possesing a remote tuner for the room's only television set. The chaos that would normally result makes it clear why we avoid such situations in the real world, and by analogy why we would be prudent to do so in our programming world.
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/22/91)
In article <1991Jun20.003529.27557@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes: >> ... it still seems that an object which is the target of multiple references >>is completely analogous to a label which is the target of multiple GoTo's. >Bill, I agree with most of what you are saying, but I don't think this >is the reason for considering gotos harmful. If it were then we would >also ban routines being called from multiple places. The distinction between labeled points in a program and side-effect free procedures is that any call to a procedure has the same fixed, and comparatively simple effect, which includes returning control to the point of invocation, whereas the effect of a goto to a particular label depends heavily upon the locations of other goto's to that same label. It's an issue of simplicity of semantics and of separation of concerns. I suppose (by dangerous analogy) that if the multiple references to an object couldn't be used to change its value, then references would be perfectly safe too.
knight@mrco.carleton.ca (Alan Knight) (06/23/91)
In article <1991Jun21.215959.13966@cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes: >In article <1991Jun19.001829.28317@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes: > ... >>As object oriented programming reflects the real world, it seems that >>references will be inevitable. > >At the risk of getting back into those dangerous analogies, note that >referencs semantics really entail multiple larger objects routinely sharing >possesion of smaller objects. For very good reasons, this rarely happens >in the real world. Imagine, for example, several people in a room each >possesing a remote tuner for the room's only television set. The chaos >that would normally result makes it clear why we avoid such situations in >the real world, and by analogy why we would be prudent to do so in our >programming world. The phrase "larger objects ... sharing possession of smaller objects" implies a physical part-of relationship, sharing of which doesn't often happen in the real world. That doesn't mean that objects aren't shared. In fact, in the "real" world that I live in, objects are usually shared, and copying is fairly rare. At my house, we have one television set which is shared between all the residents. It's true that there's only one remote control, but if my wife decides to change the state of the television set, it certainly affects the copy that I'm referencing. Copying semantics (in which as soon as I walk into the room I get my own television to look at) would be rather disconcerting. Copy-on-write would be rather entertaining, if anyone who changed the channel got a new television set. I'd soon be able to open my own electronics store. I'm not sure what would happen to the reference to the TV from the bookcase it sits on, though. We might need to clone quite a bit of stuff. To actually make a point: The real world has state and reference semantics all over the place. There may be good arguments for avoiding them, but the claim that they are not used in the real world is not one of them. -- -- Alan Knight knight@mrco.carleton.ca +1 613 788 5783 Support Dept. of Mechanical and Aeronautical Engineering the Carleton University, Ottawa, Ontario, Canada, K1S 5B6 LPF
barmar@think.com (Barry Margolin) (06/24/91)
In article <1991Jun22.175434.21450@cunews.carleton.ca> knight@mrco.carleton.ca (Alan Knight) writes: >In article <1991Jun21.215959.13966@cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes: >>At the risk of getting back into those dangerous analogies, note that >>referencs semantics really entail multiple larger objects routinely sharing >>possesion of smaller objects. For very good reasons, this rarely happens >>in the real world. Imagine, for example, several people in a room each >>possesing a remote tuner for the room's only television set. > In fact, in the "real" world that I live in, objects are usually >shared, and copying is fairly rare. At my house, we have one >television set which is shared between all the residents. It's true >that there's only one remote control And reference semantics still make sense for the remote control as well, precisely *because* there's only one. If you give the remote control to your wife, then you must drop your reference to it and she must add her reference to it. However, it's still the same remote control, and any state (its color, the strength of its battery, its serial number, and, most importantly, its *identity* (in languages that support identity, rather than equivalence, testing)) must be maintained when moving it. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/25/91)
In article <6375@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: .... >> There's not much sharing in a language like say FORTRAN or BASIC, >> but I really doubt the functional language camp would claim such languages >> either. >There is a h**l of a lot of sharing in Fortran. It's the major factor >inhibiting the parallelisation that the scientific computing people would >like to get. Where is the sharing? Destructive assignment to array >elements. Think > pointer : set of objects of base type :: integer : array ... > Just because it doesn't LOOK like a pointer doesn't mean that it > doesn't ACT like a pointer and have the PROBLEMS of a pointer. There seems to be a [meta?]semantic problem here. Reference variables and integers have very different [programming] semantics. If two reference variables R and S point to the same object, then performing an operation on R will cause a visible (and all too often unwanted) change to S. This is a more complex semantic that the everyday semantic in which all variables are independent. This complexity is apparent in the difficulty of both programmer understanding as well as formal proof rules. If two integer variables I and J both happen to have the value 17, then using I to update an entry in an array A has no effect on J. The semantics of this situation are of the simple, everyday sort. From a complexity of semantics perspective, the analogy just doesn't hold. Now apart from COMMON, EQUIVALENCE and a few funny addressing games there isn't much literal sharing in Fortran. So I wonder whether your remark about ` Destructive assignment to array elements' isn't really a comment upon the sharing implicit in the high degree of coupling often found in Fortran programs. Certainly one can introduce alternative mechanisms (such as references instead of pointers) which carry along some of the old problems you were trying to eliminate. However, I don't see why arrays and integers introduce the same problems as objects and references do.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/25/91)
In article <1991Jun24.221402.14058@cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes: > In article <6375@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. > O'Keefe) writes: > > Just because it doesn't LOOK like a pointer doesn't mean that it > > doesn't ACT like a pointer and have the PROBLEMS of a pointer. > > There seems to be a [meta?]semantic problem here. Reference variables > and integers have very different [programming] semantics. No meta-semantic problem, just a reading problem. > If two reference variables R and S point to the same object, then > performing an operation on R will cause a visible (and all too often > unwanted) change to S. This is simply false. Indeed, the change is visible *through* S precisely because S *hasn't* changed. If you are trying to argue by example that failure to distinguish between references and the things referred to is a source of confusion and mistakes, we're agreed. For concreteness, let's use a C example: char shared_object = 'a'; char *R = shared_object; char *S = shared_object; *R = 'b'; Now, after this assignment through R, how (be precise) has S itself changed? It is still the same bit pattern that it was before. It is still equal to R. It still refers to the very same object that it did before the assignment through R took place. R hasn't changed, and neither has S. *R has changed, and so therefore has *S, but R is not *R and *S is not S. In exactly the same way, I can do char shared_objects[300] = { ..., 'a', ... }; int R = 17; int S = 17; shared_objects[R] = 'b'; Now, after this assignment using R, neither R nor S has changed. But although there wasn't any assignment of the form shared_objects[S], shared_objects[S] has in fact changed. > If two integer variables I and J both happen to have the value 17, then > using I to update an entry in an array A has no effect on J. The > semantics of this situation are of the simple, everyday sort. > From a complexity of semantics perspective, the analogy just doesn't > hold. But I have just illustrated in tedious detail above the kindergarten- level fact that the analogy _does_ hold. And in fact in the language Euclid the compiler was supposed to generate verification conditions for pointers in exactly the same way that it was to generate verification conditions for arrays. But, I hear you exclaim, pointers can point anywhere, while uses of arrays make it plain which array can be affected! Euclid pointers pointed into "zones", and two pointers to the same type of element could only refer to the same object if they pointed into the same zone, so "pointing anywhere" is not an essential aspect of pointer-nature. -- I agree with Jim Giles about many of the deficiencies of present UNIX.
jcm@mstr.hgc.edu (James McKim) (06/26/91)
In article <1193@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: > From Eiffel 2.2 onwards >(that's nearly 2 years ago), a class variable can be declared as "expanded". >This means it gets value semantics - i.e. every assignment is a copy. Eiffel 3 >allows a _class_ to be declared as expanded, so every instance is distinct. In >fact, in ISE's version of Eiffel 3, expanded objects will be _implemented_ >using references, but the compiler will enforce _value_ semantics - i.e. it >will guarantee no aliasing. > Rick, In version 2.3 there is a restriction on the base class of an expanded type. Namely its Create routine can have no parameters. Also, declaring and using an instance of an expanded type is legal without explicitly calling Create, but does not automatically result in the initialization of the expanded object's attributes or the execution of the Create routine. Consequently I have restricted my use of expanded types mainly to stateless objects such as those containing only constants and simple queries. Does version 3 address these issues? > >-- >Rick Jones, Tetra Ltd. Maidenhead, Berks, UK rick@tetrauk.uucp >Chairman, NICE (Non-profit International Consortium for Eiffel) > >Any fool can provide a solution - the problem is to understand the problem -- Jim *------------------------------------------------------------------------------* Jim McKim (203)-548-2458 _Give_ people fish and they eat for a day. Internet: jcm@mstr.hgc.edu _Teach_ people to fish and they eat for a lifetime.
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/27/91)
In article <1991Jun22.175434.21450@cunews.carleton.ca> knight@mrco.carleton.ca (Alan Knight) writes: >>>As object oriented programming reflects the real world, it seems that >>>references will be inevitable. >>At the risk of getting back into those dangerous analogies, note that >>referencs semantics really entail multiple larger objects routinely sharing >>possesion of smaller objects. For very good reasons, this rarely happens >>in the real world. Imagine, for example, several people in a room each >>possesing a remote tuner for the room's only television set. The chaos ... > The phrase "larger objects ... sharing possession of smaller >objects" implies a physical part-of relationship, sharing of which >doesn't often happen in the real world. That doesn't mean that >objects aren't shared. The issue here certainly wasn't that objects aren't and shouldn't be shared -- both in the programming and in the real world. The concern was that multireferences to objects entails the simultaneous _shared possession_ of those objects by other entities in the system. > In fact, in the "real" world that I live in, objects are usually >shared, and copying is fairly rare. At my house, we have one >television set which is shared between all the residents. It's true >that there's only one remote control, but if my wife decides to change >the state of the television set, it certainly affects the copy that >I'm referencing. In your world then there is only one television object whose use is shared by several other entities. The entities are aware of each other and that in order to function properly, they must set up and obey certain conventions regarding the use of the television. [Supposing that a remote controller is an adequate analogue of a reference to a TV object,] you then follow the simplifying convention of only having ONE reference to your TV and of sharing (at different times) the use of that reference. If you had several TV's and remote tuners which could selectively control any TV, then the physical situation here might begin to approach the complexity inherent in reference semantics. > Copying semantics (in which as soon as I walk into the room I get my >own television to look at) would be rather disconcerting. >Copy-on-write would be rather entertaining, if anyone who changed the >channel got a new television set. ... As I said early in this discussion, copying of large objects is difficult and expensive, and it should be avoided if at all possible. > To actually make a point: The real world has state and reference >semantics all over the place. There may be good arguments for >avoiding them, but the claim that they are not used in the real world >is not one of them. Objects in the real world certainly have state. Actual examples of reference semantics, however, seem to be hard to come up with. Objects are visible and accessible to multiple entities in a physical environment, just as variables are in a programming environment, but that's clearly not analogous to having multiple references.
ogden@seal.cis.ohio-state.edu (William F Ogden) (06/27/91)
In article <6495@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >> > Just because it doesn't LOOK like a pointer doesn't mean that it >> > doesn't ACT like a pointer and have the PROBLEMS of a pointer. >> There seems to be a [meta?]semantic problem here. Reference variables >> and integers have very different [programming] semantics. >No meta-semantic problem, just a reading problem. ... > If you are trying to argue by >example that failure to distinguish between references and the things >referred to is a source of confusion and mistakes, we're agreed. Where we seem to disagree is on the English language meaning (metasemantics) of the phrase `different programming semantics'. What I understand the phrase to mean is that the formal operational or denotational semantics for the two constructs are different. [C pointer and array examples deleted for brevity] ... >> From a complexity of semantics perspective, the analogy [between >>objects with references and arrays with integer indices] just doesn't >> hold. >But I have just illustrated in tedious detail above the kindergarten- >level fact that the analogy _does_ hold. And in fact in the language >Euclid the compiler was supposed to generate verification conditions >for pointers in exactly the same way that it was to generate >verification conditions for arrays. ... Now just based on the fact that objects with references are `a source of confusion and mistakes', while integers and arrays are not, we would expect that the two constructs are semantically distinct. And so they are. Semantically, an integer variable J is assigned a value of mathematical type Z (the integer type); an array variable A is assigned a value of type (Z -> Item), where Item is the type of the entries in A. For program objects of underlying type Item with reference semantics, things are a bit more complicated. We need to establish a set Item_Ref of reference objects and a function Item_of: (Item_Ref -> Item). A reference variable R can then be assigned a value of type Item_Ref. A reassignment R := S just changes the Item_Ref assigned to R, but not the underlying Item_of function. On the other hand, a basic class operation on R will typically change the Item_of function, so that Item_of( R ) has the appropriate new value. Clearly, arrays and reference objects have different semantics. Now you might observe that an array A of Items is just a function from a set (Z) into the Item set, while a type Item with reference semantics is likewise just function from a set (Item_Ref) into the same Item set, and wonder what the big difference is which accounts for the confusion and mistakes by programmers. The answer is that the Item_Ref set and Item_of function are both implicit and hidden in the language notation. You can't modify an entry in array A without explicitly referencing A in the program text, so it won't be any surprise when subsequent uses establish that A has changed. This certainly isn't true of the hidden Item_of function.
barmar@think.com (Barry Margolin) (06/27/91)
In article <1991Jun26.204549.27784@cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes: >Objects in the real world certainly have state. Actual examples of reference >semantics, however, seem to be hard to come up with. Objects are visible >and accessible to multiple entities in a physical environment, just as >variables are in a programming environment, but that's clearly not analogous >to having multiple references. Why isn't it? To continue the TV analogy, consider a class TV-WATCHER (representing people who watch TV), with a slot TV-BEING-WATCHED, and a class TELEVISION-SET. If several TV-WATCHERs are in the same room, they would all be watching the same TV, so they would have references to the same TELEVISION-SET in their TV-BEING-WATCHED slots. Sharing this reference is necessary to deal with state changes in the TELEVISION-SET. For instance, if one TV-WATCHER changes the channel, all the TV-WATCHERs are now watching a different channel. If each TV-WATCHER had a copy of the TELEVISION-SET object, propagating these state changes would be harder (you'd have to maintain a list of all the equivalent TELEVISION-SETs). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar