I am trying  to work through the concept of the @property decorator with 
respect to object oriented programming.

I believe that I understand how the @property and @<variableName>.setter work - 
and that they are used to turn what looks like direct access to instance 
variables into method calls in an object.    It seems like these two decorators 
are essentially fancy substitutes for traditional getter and setter methods.  
But, I'm having a hard time understanding why these names were chosen. 

I have the following example code:


class Employee():

    def __init__(self, name, salary):
        self.__name = name
        self.__salary = salary

    @property
    def salary(self):
        print('Getting salary of', self.__name, 'which is:', self.__salary)
        return self.__salary

    @salary.setter
    def salary(self, newSalary):
        print('Setting salary of', self.__name, 'to:', newSalary)
        self.__salary = newSalary


# Test code:
employee1 = Employee('Joe Schmoe', 99999)
employee2 = Employee('Jane Smith', 123456)

print(employee1.salary)
print(employee2.salary)

employee1.salary = 100000
employee2.salary = 222222

print(employee1.salary)
print(employee2.salary)


When it runs, I get the results I expect:

Getting salary of Joe Schmoe which is: 99999
99999
Getting salary of Jane Smith which is: 123456
123456
Setting salary of Joe Schmoe to: 100000
Setting salary of Jane Smith to: 222222
Getting salary of Joe Schmoe which is: 100000
100000
Getting salary of Jane Smith which is: 222222
222222


My questions about this are really historical.  From my reading, it looks like 
using an @property decorator is a reference to an older approach using a built 
in "property" function.  But here goes:

1) Why were these decorator names chosen?  These two names @property and 
@<name>.setter don't seem to be very clear to me.  At a minimum, they don't 
match.  Wouldn't decorator names like @<name>.getter and @<name>.setter have 
been better - more explicit?    

2)  Alternatively, if the getter was going to use the @property decorator, then 
it would seem complimentary  to have the decorator name for the associated 
setter function to have the word "property" in its also, something like 
@propertySetter.  

3)  If I create a method with the @property decorator, is there anything else 
that is implied about the name of the method other than you can now refer to 
the <objectName>.<name> - which calls the appropriate method?  My 
guess/understanding is that in my example above, "salary" is considered the 
property name, which is how you would refer to it outside of the object. Inside 
the class, you use the property name as the name of both the setter and the 
getter methods.  Is that the right way to think about it?


Finally, it seems very odd to me that when you use the @property decorator and 
the @<variableName>.setter, that both of the methods that are decorated need to 
have the same name (but of course different set of parameters.)  As a teacher, 
this seems like it would be an extremely difficult concept to get across to 
students, as this does not work the same way as other Python functions (and 
methods).  Without a decorator, the second function of the same name overrides 
an earlier function of the same name, as in this simple example:

def myFunction( ):
    print('In first version of myFunction')

def myFunction( ):
    print('In second version of myFunction')

myFunction()

Which prints:  In second version of myFunction




My most recent language before Python was ActionScript 3 (the language of 
Flash).  It implemented a similar concept of being able to use what appeared to 
be an explicit data reference which turns into a method call, like this example 
(from StackOverflow):

private var _loggy:String;

public function get loggy ():String
{
  return _loggy;
}

public function set loggy ( loggy:String ):void
{
  // checking to make sure loggy's new value is kosher etc...
  _loggy = loggy;
}
This syntax made the concept easy to understand and implement in an 
ActionScript class (even though it also uses the same name for both function).

I do NOT want to start any kind of language flame war.  I am really just trying 
to understand the reasons behind why this concept is implemented in Python this 
way, so that I can wrap my head around it and teach it effectively in my 
classes.

Irv

-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to