Uniform access principle

Python properties may be used to allow a method to be invoked with the same syntax as accessing an attribute. Whereas Meyer's UAP would have a single notation for both attribute access and method invocation (method invocation syntax), a language with support for properties still supports separate notations for attribute and method access. Properties allow the attribute notation to be used, but to hide the fact that a method is being invoked instead of simply retrieving or setting a value.

As such, Python leaves the option of adherence to UAP up to the individual programmer. The built-in @property function provides a simple way to decorate any given method in attribute access syntax, thus abstracting away the syntactical difference between method invocations and attribute accesses.[4]

In Python, we may have code that access an Egg object that could be defined such that weight and color are simple attributes as in the following

"""
>>> egg = Egg(4.0, "white")
>>> egg.color = "green"
>>> print(egg)
Egg(4.0, green)
"""

class Egg:
    def __init__(self, weight, color) -> None:
        self.weight = weight
        self.color = color

    def __str__(self) -> str:
        return f"{__class__.__name__}({self.weight}, {self.color})"

Or the Egg object could use properties, and invoke getter and setter methods instead

# ...(snip)...
class Egg:
    def __init__(self, weight_oz: float, color_name: float) -> None:
        self.weight = weight_oz
        self.color = color_name
        
    @property
    def color(self) -> str:
        '''Color of the Egg'''
        return to_color_str(self._color_rgb)

    @color.setter
    def color(self, color_name: str) -> None:
        self._color_rgb = to_rgb(color_name)   

    @property
    def weight(self) -> float:
        '''Weight in Ounces'''
        return self._weight_gram / 29.3

    @weight.setter
    def weight(self, weight_oz: float) -> None:
        self._weight_gram = 29.3 * weight_oz

    # ...(snip)...

import webcolors

# class Egg:

def to_color_str(rgb: webcolors.IntegerRGB) -> str:
    try:
        return webcolors.rgb_to_name(rgb)
    except ValueError:
        return webcolors.rgb_to_hex(rgb)
    
def to_rgb(color_name: str) -> webcolors.IntegerRGB:
    try:
        return webcolors.name_to_rgb(color_name)
    except ValueError:
        return webcolors.hex_to_rgb(color_name)


if __name__ == "__main__":
    import doctest
    doctest.testmod()

Regardless of which way Egg is defined, the calling code can remain the same. The implementation of Egg can switch from one form to the other without affecting code that uses the Egg class. Languages which implement the UAP have this property as well.

Consider the following

y = Egg.new("Green")
y.color = "White" 
puts y.color

Now the Egg class could be defined as follows

class Egg
  attr_accessor :color
  def initialize(color)
    @color = color
  end
end

The above initial code segment would work fine with the Egg being defined as such. The Egg class could also be defined as below, where color is instead a method. The calling code would still work, unchanged if Egg were to be defined as follows.

class Egg
  
  def initialize(color)
    @rgb_color = to_rgb(color)
  end

  def color
     to_color_name(@rgb_color)
  end
 
  def color=(color) 
     @rgb_color = to_rgb(color)
  end

  private
  def to_rgb(color_name)
     .....
  end

  def to_color_name(color)
     ....
  end
end

Note how even though color looks like an attribute in one case and a pair of methods in the next, the interface to the class remains the same. The person maintaining the Egg class can switch from one form to the other without fear of breaking any caller's code. Ruby follows the revised UAP, the attr_accessor :color only acts as syntactic sugar for generating accessor/setter methods for color. There is no way in Ruby to retrieve an instance variable from an object without calling a method on it.

Strictly speaking, Ruby does not follow Meyer's original UAP in that the syntax for accessing an attribute is different from the syntax for invoking a method. But here, the access for an attribute will always actually be through a function which is often automatically generated. So in essence, either type of access invokes a function and the language does follow Meyer's revised Uniform Access Principle.

The C# language supports class properties, which provide a means to define get and set operations (getters and setters) for a member variable. The syntax to access or modify the property is the same as accessing any other class member variable, but the actual implementation for doing so can be defined as either a simple read/write access or as functional code.

public class Foo
{
    private string _name;

    // Property
    public int Size
    {
        get;    // Getter
        set;    // Setter
    }

    // Property
    public string Name
    {
        get { return _name; }     // Getter
        set { _name = value; }    // Setter
    }
}

In the example above, class Foo contains two properties, Size and Name. The Size property is an integer that can be read (get) and written (set). Similarly, the Name property is a string that can also be read and modified, but its value is stored in a separate (private) class variable _name.

Omitting the set operation in a property definition makes the property read-only, while omitting the get operation makes it write-only.

Use of the properties employs the UAP, as shown in the code below.

    public Foo CreateFoo(int size, string name)
    {
        var foo = new Foo();
        foo.Size = size; // Property setter
        foo.Name = name; // Property setter
        return foo;
    }

C++ has neither the UAP nor properties, when an object is changed such that an attribute (color) becomes a pair of functions (getA, setA). Any place in that uses an instance of the object and either sets or gets the attribute value (x = obj.color or obj.color = x) must be changed to invoke one of the functions. (x = obj.getColor() or obj.setColor(x)). Using templates and operator overloading, it is possible to fake properties, but this is more complex than in languages which directly support properties. This complicates maintenance of C++ programs. Distributed libraries of C++ objects must be careful about how they provide access to member data.

JavaScript has had support for computed properties since 2009.[5]