Re: Principle of Uniform Reference

Re: Principle of Uniform Reference

[Adam Beneschan]

Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
> In article <RBREWER.95Apr11025011@rwb114.rh.psu.edu>, 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

Re: Principle of Uniform Reference

[Robert Dewar]

Adam, in your discussion of uniform reference you say that you should not
use constants, but instead functions, but here is a case where Ada does
in fact provide uniform reference:

   x         reference to constant x
   x         call of function x

so if you decide to later replace a constant by a function, clients do
not need to be modified. of course I am assuming here that the constant
is deferred so that details of its structure are appropriately hidden.

The notion of using functions and procedures to abstract simple access
functions is certainly a reasonable one. In GNAT, all attributes in the
tree are function calls, and actually, since there are several levels
of abstraction in the data structures, a simple access to the tree, say
for the type of a node, requires three levels of function calls.

Eventually, when we implement inlining, these three levels will disappear
(but they are there today, which is why I have noted in the past that you
can expect the eventual performance of the GNAT front end to be a factor
of several faster than it is today).