From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e676bec04de25560 X-Google-Attributes: gid103376,public From: adam@irvine.com (Adam Beneschan) Subject: Re: Principle of Uniform Reference Date: 1995/04/21 Message-ID: X-Deja-AN: 101283313 sender: usenet@irvine.com (News Administration) references: <1995Apr11.122050@di.epfl.ch> organization: Irvine Compiler Corp., Irvine, California, USA newsgroups: comp.lang.ada Date: 1995-04-21T00:00:00+00:00 List-Id: Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes: > In article , rbrewer@rwb114.rh.psu.edu (Robert W. Brewer) writes: > |> I've been going through _Object-oriented Software Construction_ by > |> Bertrand Meyer lately. One thing he mentions near the beginning is the > |> "Principle of Uniform Reference," where he states that a language > |> should use the same notation for extracting the attribute "a" of > |> object "x" regardless of whether it is computed or stored. > |> > > summary: > > In Ada syntax -> stored: x.a, computed: a(x) > > In Eiffel syntax -> stored and computed: x.a; > > |> This makes a lot of sense to me. What are the tradeoffs between the > |> Eiffel way and the Ada way, and is this type of thing a big deal in > |> practice? > > Are they two different concepts or one? _Object-oriented Software > Construction_ is a good book but it is not particularly impartial > and objective. > > Your question is a good example. There are two cases that are quite > distinct. Suppose that x is an object, then x.a is also an object but > a(x) is a value. Now if x is a value then x.a and a(x) are values. > In Eiffel the distinction between an object and a value is much more > fuzzy, in part because of the principle of uniform reference. > > Now has Eiffel unified the concepts or has it just confused them? I'm not an Eiffel expert, or an OO expert for that matter, but lack of expertise has never stopped me from posting in the past . . . I believe Eiffel has indeed unified the concepts. I don't think there's anything in Eiffel that treats "objects" differently from "values", and in fact, in the Eiffel way of thinking, it doesn't seem to make sense to refer to an "object" vs. the "value of an object" as two separate concepts. There's no syntax in the language that I know of, that makes a distinction between whether it requires an "object" or a "value". > The distinction is not critical but I find it to be very valuable > during the analysis and design phases. I'm curious as to why this would be. Can you provide an example? My feeling here is that the "Eiffel way of thinking", which seems to involve looking at everything as an abstract data type, is a significantly different paradigm from what most of us with experience in non-OO lanaguages are used to. It's different enough that switching from the "Ada/Pascal/PL-I/etc. way of thinking" may require that we discard some concepts that are familiar to us. Thus, while making a distinction between Objects and Values may make a lot of sense while designing in a non-OO language, it's possible that when we start using OO paradigms we need to start thinking differently, and this distinction may get in the way. I'm impressed enough with the ideas behind Eiffel, that I've been trying to use the general philosophy when designing Ada 83 code. Although I've written some packages with the Eiffel philosophy in mind, I haven't written a complete program yet, so it's too early for me to decide how useful a complete "paradigm shift" would be. Nevertheless, I like what I see so far. ---- By the way, to address the original issue, it's possible to adopt the Principle of Uniform Reference in Ada, even though the language has two different syntaxes. The method is to use only the function call syntax a(x), whether the attribute is computed or stored. If the attribute is stored, the body of a(x) would be a very simple body that just returns the stored value. You can PRAGMA INLINE the function if you're worried about efficiency. I definitely recommend this approach (even in Ada 83). Even if something looks like it should be a constant, so that you can stick the constant in the package spec and use the x.a syntax, there is one great benefit to making it a function call anyway: If, somewhere in the future, you decide that the attribute really ISN'T a constant, all you have to do is change the function body, and you don't have to go searching for all the places everywhere else in your program(s) where this attribute is used. This is consistent with the philosophy behind abstract data types: the user of the attribute shouldn't care whether the attribute is computed or is stored in memory or is a constant, so it should be able to use the same syntax regardless of how the attribute ends up being implemented. -- Adam