Talk:Uniform access principle

Decided to change this page to include more information, more language samples, and hopefully a less ruby vs python feel. Both have features which make them "close" to "proper" UAP, but neither gets it completely right. I think this is, mostly, because Bertrand's idea of "right" is emboddied in the Eiffel programming language, which no one else has stolen enough of (sic) to get UAP completely in another language.

I'll be adding Java and a few other languages that are OO-like to show varying degrees of UAP.

Mattreynolds 18:52, 3 March 2006 (UTC)

so how about adding an example in eiffel? (eMBee 1.202.193.148 (talk) 14:44, 5 March 2014 (UTC))

I contest that Ruby does not have strict UAP. There is only one way to access properties of an Object: Methods. Even the c2-wiki states this. The attr_reader in the code sample is not even syntactic sugar, just a method generating the accessor method dynamically. The Ruby interpreter itself has no idea of what an attribute is. Access to an instance variable is always hookable. I just glanced over it, but I find nothing in Bertrands column that is not present in Ruby. —Preceding unsigned comment added by 142.162.19.124 (talk) 04:43, 29 November 2009 (UTC)

As I'm not very familiar with Ruby I can't say for sure whether it does or doesn't have UAP. Initially Meyers' favored notation was the method call notation: a.attr(), but his point was you either use a.attr() for both accessing attributes or invoking methods or you use a.attr. One or the other, not both.

A language with properties does not follow the uniform acess principle. A property allows you to invoke a method, but have it look like you're just accessing a member varible. Languages with properties still allow you to access methods with the a.method() syntax. This is contrary to Meyer's original UAP.

As we've seen over the 20 or so years since the UAP was introduced, languages that strictly follow it are few. Instead 'properties' are much more prevalent in computer languages. The reason for this is that information is lost to the software developer if only a single syntax is provided by the language.

With separate attribute and method notations, the method syntax (a.attr()) provides a hint to the developer that there's processing involved in the call, and the attribute syntax (a.attr) provides the hint that this just access a member variable (or invokes minimal processing). In medium/large systems a single software developer may not be very familiar with all the objects in the system. When the 'hints' provided by the non-UAP system are present the developer can make an informed choice as to whether they should assign a returned attribute value to a local variable or just retrieve the attribute multiple times. In the event that the returned value is the result of an extensive computation, doing the latter (multple retrieves) instead of the former (assign to local variable) can have a substantial negative performance impact. Alternatively, always caching a returned value instead of retrieving it can have a substantial negative memory impact. There is benefit in providing notations for both method invocations and simple attribute accessess.

If I had a source for this, instead of my own opinion, I'ld put the above in the article as well. In short, there are good reasons to prefer properties over the UAP. That is why you don't see the UAP much in programming languages. --71.214.223.133 (talk) 22:49, 14 January 2010 (UTC)

Re Lisp Example

First of all people, a language does not 'enforce' UAP. It either implements (follows) it or it doesn't. Its a property of the language, not of code implemented in the language.

That said, it may be beneficial to have a Common Lisp example. As I'm not really familiar with the language, I can't say for sure whether, or to what extent, that it follows the UAP. An example should have a class that has both a method and an attribute. The example should show how the method is invoked, and should show how the attribute is set. If both of these types of access have THE SAME SYNTAX, then the language follows the UAP (original). If not, it may be that this is something like RUBY where attribute access is always through a function that is generally automatically generated, but which can be reimplemented. In which case it would follow the revised UAP.

The important thing here is syntax. The UAP is all about syntax. A comment about something being 'syntactical sugar' in the Ruby section indicated the author didn't really understand the UAP. --Aflafla1 (talk) 08:39, 17 October 2013 (UTC)

After studying the previously appearing Common Lisp example some more, I would say that it does, at least partially, implement the original UAP. The syntax of directly setting an attribute or of invoking a function which sets the attribute (and does other stuff) looks to be the same. Anyone more experienced in Common Lisp care to chime in? --Aflafla1 (talk) 09:21, 17 October 2013 (UTC)

what looks the same, is quite different:

(setf (weight *egg*) 16.9) ;; using the accessor function
(setf (slot-value *egg* '%weight) 16.9) ;; accessing the slot directly

they only look similar because lips syntax is so minimalistic.

the point of UAP is that you can replace the direct access to an attribute with a function to intercept that access without changing the code that accesses it..

as the python and ruby examples show, you can add accessor functions later without requiring code rewrites to use them.

in common lisp, (slot-value) will always access the slot directly, regardless of the existence of an accessor function. there is no way to prevent that, so if the accessor function is added later, any code that until then used (slot-value) needs to be changed to use the accessor function instead.

so while ruby and python sort of violate UAP because they have one syntax for member functions, and another syntax for accessors, they do support UAP because the syntax for accessor functions and direct access is the same. common lisp on the other hand does not even support UAP because the way to use accessor functions is distinct from direct access. to make UAP work, one would have to replace (slot-value) with a different function that acts like an accessor function, but somehow retain the original (slot-value) function (with a different name?) to be able to actually access the slots from the replacement function.

to put it in a different way, in ruby and python, once accessor functions are created, their use is enforced, whereas in common lisp, any code that bypasses accessor functions can never be forced to use them without actually changing the code in question. --(eMBee1.202.193.148 (talk) 15:36, 5 March 2014 (UTC))

The Self Language is UAP

Just to have an example of a language other than Eiffel that does do UAP fully, the Self programming language perfectly follows Meyer's notion of UAP if I'm not mistaken :)
--RProgrammer (talk) 07:56, 5 September 2016 (UTC)