Syntactically Equivalent Members And Properties

One of the most important language features supporting SyntacticallyTransparentRefactorings

E.g. in EiffelLanguage, VisualBasic, and PythonLanguage, but not in CeePlusPlus or JavaLanguage. An object may first make publicly available data members.

E.g.

        struct Point { int x, y; }

Users access this directly

        Point p; p.x = 1; p.y = 2;

Later, however, the internal representation may be changed, requiring a functional interface:

        class Point { 
          private:
             float angle, radius;
          public:
             void set_x(int);
             void set_y(int);
        };

        Point p; p.set_x(1); p.set_y(2);

Changing from data member access to setter/getter access in CeePlusPlus is not syntactically transparent.

In languages like EiffelLanguage, CeeSharp, and PythonLanguage, however, you can declare properties. When assigned to, a property calls a set method; when read from, a property invokes a get method. In hypothetical CeePlusPlus syntax:

        class Point { 
          private:
             float angle, radius;
          public:
             property int x {
               int get() { return (int)( sin(angle)*radius; }
               int set(int argx)  {                    angle = atan2(argx,y); 
                   radius = sqrt(argx*argx+y*y); 
                   return x   
               }
             }
             property int y ....
        };

        Point p; p.x=1; p.y=2;

Thus, the users of the class do not need to be changed. Although they probably need to be recompiled.

"OWL", a SmalltalkLanguage-like OO language used internally at EDS in the '80s had that property too: Properties and methods were interchangeable. In fact, one common technique in OWL was to change a property to a rule-based expert system that computed the "property" value. "Properties" and "methods" were just two of a dozen or more different ways a class could respond to messages. Several different rule based expert system processors could be used instead, and you could write your own.

Very interesting tool, that "OWL" was. -- JeffGrigg

In the following languages, direct access of properties implicitly invokes invisible getter and setter functions, which can be overridden.

AccessOrientedProgramming takes another approach to solve this problem.

The way you deal with this in CeePlusPlus and JavaLanguage, of course, is to follow the advice that any introductory course in these languages is happy to give you. Make all data members private. And write getter/setter functions as needed, which may be never, or only a few. (Unless you're writing a JavaBean, or a UnitTest, in which case you may find you need to write a lot).

"Properties" are mere SyntacticSugar for the above, as DylanLanguage and JavaScript both demonstrate. Smalltalk does this by convention as well--though in Smalltalk, slots and messages occupy a separate namespace, so "foo" can both be a slot name and an accessor functions (and "foo:" is the name of the mutator). That said, properties are quite useful SyntacticSugar.

CeePlusPlus progammers might try the following: (Java progammers, lacking a preprocessor--even one as lousy as cpp--are screwed).

 #define PROPERTY(type,name)      private:          type m_##name;      public:          type &get_##name () const { return m_##name; }          void set_##name (const type &long_name_because_no_hygenic_macros) {              m_##name = long_name_because_no_hygenic_macros;          }

Just put PROPERTY(int,age) or whatever in your class definition and BobsYourUncle?. Feel free to adjust the above macro to match the coding conventions at your site.

CategoryRefactoring