Simple properties can be faked more easily than multi-properties (like rules).
I.e.

class X {
    private:
        int m_area;
        rule validate_area : m_x, m_y {
            if (m_x < 0) m_x = 0;
            if (m_y < 0) m_y = 0;
            m_area = m_x * m_y;
            return;
        }
    public:
        int m_x, m_y;
        int GetArea();
};

This type of thing doesn't scale well without direct compiler support, and it's
use is tedious and error-prone.

Paul Mensonides

"Michael Lee Finney" <michael.finney@acm.org> wrote in message
news:MPG.156e1ef4624e609298973c@news.lynchburg.net...
| In article <9dvvor$1i7$1@news.ias.unu.edu>,
| zunino@ias.unu.edu says...
| > "Michael Lee Finney" <michael.finney@acm.org> wrote in message
| > news:MPG.156bba557914ef6f989732@news.lynchburg.net...
| > > Syntactic sugar is one of the primary enablers of
| > > progress.
| >
| > Hello All.
| >
| > Since we are having this talk about "syntactic sugar" and since I have seen
| > the addition of "properties" considered by other people, I would like to
| > hear your opinions on the subject. It is my understanding that there is
| > nothing they provide that a pair of accessor methods can not (please,
| > correct me if I am missing something), but still I think they could make a
| > "sweet" addition to the language, probably making it more attractive to
| > newcomers (specially the ones with a VB background :) and facilitating code
| > to be written and read. What do you think? What syntax would you suggest?
| >
| > Similar to C#?
| >
| > class Foo
| > {
| > public:
| >     int bar
| >     {
| >         get { return value_; }
| >         set { value_ = value; }
| >     }
| > private:
| >     int value_;
| > };
| >
| > Or something else?
| >
| > Notice that, for the set accessor, there is an implicit parameter named
| > "value" that must be of the same type as (or implicitly convertible to the
| > type of) the property.
| >
| > Thanks for your ideas.
| >
| > Ney Andr    de Mello Zunino.
| >
| > "Take of the fruit,
| >     But guard the seed..."
|
| The code below will implement a "property" to a class
| variable so that only the class can directly alter the
| variable, but it appears to be a simple variable to
| the user. The right to use or change the variable can
| be controlled independently for the use.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Michael Lee Finney" <michael.finney@acm.org> wrote in message
news:MPG.156bba557914ef6f989732@news.lynchburg.net...
> Syntactic sugar is one of the primary enablers of
> progress.

Hello All.

Since we are having this talk about "syntactic sugar" and since I have seen
the addition of "properties" considered by other people, I would like to
hear your opinions on the subject. It is my understanding that there is
nothing they provide that a pair of accessor methods can not (please,
correct me if I am missing something), but still I think they could make a
"sweet" addition to the language, probably making it more attractive to
newcomers (specially the ones with a VB background :) and facilitating code
to be written and read. What do you think? What syntax would you suggest?

Similar to C#?

class Foo
{
public:
    int bar
    {
        get { return value_; }
        set { value_ = value; }
    }
private:
    int value_;
};

Or something else?

Notice that, for the set accessor, there is an implicit parameter named
"value" that must be of the same type as (or implicitly convertible to the
type of) the property.

Thanks for your ideas.

Ney Andr    de Mello Zunino.

"Take of the fruit,
    But guard the seed..."


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9dvvor$1i7$1@news.ias.unu.edu>,
zunino@ias.unu.edu says...
> "Michael Lee Finney" <michael.finney@acm.org> wrote in message
> news:MPG.156bba557914ef6f989732@news.lynchburg.net...
> > Syntactic sugar is one of the primary enablers of
> > progress.
>
> Hello All.
>
> Since we are having this talk about "syntactic sugar" and since I have seen
> the addition of "properties" considered by other people, I would like to
> hear your opinions on the subject. It is my understanding that there is
> nothing they provide that a pair of accessor methods can not (please,
> correct me if I am missing something), but still I think they could make a
> "sweet" addition to the language, probably making it more attractive to
> newcomers (specially the ones with a VB background :) and facilitating code
> to be written and read. What do you think? What syntax would you suggest?
>
> Similar to C#?
>
> class Foo
> {
> public:
>     int bar
>     {
>         get { return value_; }
>         set { value_ = value; }
>     }
> private:
>     int value_;
> };
>
> Or something else?
>
> Notice that, for the set accessor, there is an implicit parameter named
> "value" that must be of the same type as (or implicitly convertible to the
> type of) the property.
>
> Thanks for your ideas.
>
> Ney Andr    de Mello Zunino.
>
> "Take of the fruit,
>     But guard the seed..."

The code below will implement a "property" to a class
variable so that only the class can directly alter the
variable, but it appears to be a simple variable to
the user. The right to use or change the variable can
be controlled independently for the use.

Please note the essential use of macros to get a
reusable construct. Further, note that each property
has to have a pointer to its owner class. If
properties were implemented by the compiler, that
would not be necessary. I can't see how to get around
that limitation, however. On the other hand,
everything is inline (except possibly the accessor and
mutator functions), so most of the overhead would be
compiled away (probably one redundant load because of
having to use "owner" instead of "this").

Also note that I would have made "owner" a reference
instead of a pointer, but C++ frowns upon passing
"this" as a parameter in a constructor. <sigh> It
always works, and I can't see the problem with it, but
apparently there must be a reason.

A similar technique could be used to allow variable
type access for functions which take a single
parameter. Along the line of Eiffel's uniform access
policy.

This code compiles and runs using the Microsoft's
Visual C++ 6.0 compiler.

======================================================

#include <iostream.h>


#define property(                                    \
   ownerClass,  /* Name of owner class             */\
   T,           /* Type of property                */\
   name,        /* Name of property                */\
   accessPolicy,/* private, protected, public      */\
   acessor,     /* Accessor function in ownerClass */\
   mutatePolicy,/* private, protected, public      */\
   mutator)     /* Mutator function in ownerClass  */\
   class Property ## _ ## name                       \
      {                                              \
         friend class ownerClass;                    \
      private:                                       \
         ownerClass * owner;                         \
      accessPolicy:                                  \
         operator T() { return owner->acessor(); }   \
         T operator()() { return owner->acessor(); } \
      mutatePolicy:                                  \
         void operator=(T x) { owner->mutator(x); }  \
         void operator()(T x) { owner->mutator(x); } \
      } name;                                        \
   friend class ownerClass::Property ## _ ## name;


class Abc
   {
   private:
      int   $def;

      int getDef() const { return $def; }
      void setDef(int x) { $def = x; }

      float $xyz;

      float getXyz() const { return $xyz; }
      void setXyz(float x) { $xyz = x; }

   public:
      property(Abc, int, def,
         public, getDef, public, setDef);
      property(Abc, float, xyz,
         public, getXyz, protected, setXyz);

      Abc()
         {
         def.owner = this;
         xyz.owner = this;
         $def = 0;
         $xyz = 3.14;
         }
      ~Abc() {}
   };


int main()
   {
   Abc   abc;

   // Access using variable notation

   cout << "abc.$def = " << abc.def << endl;
   abc.def = abc.def + 1;
   cout << "abc.$def = " << abc.def << endl;

   cout << endl;

   // Access using operator notation

   cout << "abc.$def = " << abc.def() << endl;
   abc.def(abc.def() + 1);
   cout << "abc.$def = " << abc.def() << endl;

   cout << endl;

   // Example of controlled access

   cout << "abc.$xyz = " << abc.xyz << endl;
   // The next line will cause a compile error
   // abc.xyz = abc.xyz + 1;
   cout << "abc.$xyz = " << abc.xyz << endl;

   return 0;
   }

======================================================

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> The code below will implement a "property" to a class
> variable so that only the class can directly alter the
> variable, but it appears to be a simple variable to
> the user. The right to use or change the variable can
> be controlled independently for the use.

I have since refined the code. I reduced the number of
macro parameters by assuming names for the accessor
and mutator functions. I also changed it so that
protection of those functions is accomplished directly
in the using class rather than in the property class.
Also, the property class was templated so that if
either the accessor or mutator is not used it does not
need to be implemented in the using class. The result
is shorter and easier to read. When the compiler
reports an access error, however, the error message is
a bit less readable. This version has been compiled
and testing with Microsoft's Visual C++ 6.0, IBM's
VisualAge C++ 4.0, GCC 2.29.2 and Borland's BCC 5.5
(the $ in the names had to be changed to an _ for that
compiler as I could not quickly find a switch to allow
$ in names).

=====================================================

#include <iostream.h>

#define property(Class,Type,name)                  \
   private:                                        \
      Type $##name;                                \
      template <class T> class name##Property      \
         {                                         \
         friend class Class;                       \
         private:                                  \
            Class * owner;                         \
         public:                                   \
            operator T()                           \
               { return owner->name##Accessor(); } \
            T operator()()                         \
               { return owner->name##Accessor(); } \
            void operator=(T x)                    \
               { owner->name##Mutator(x); }        \
            void operator()(T x)                   \
               { owner->name##Mutator(x); }        \
         };                                        \
   public:                                         \
      name##Property<Type> name


class Abc
   {
   public:
      int defAccessor() const { return $def; }
      void defMutator(int x) { $def = x; }

   public:
      float xyzAccessor() const { return $xyz; }
   protected:
      void xyzMutator(float x) { $xyz = x; }

   public:
      property(Abc, int, def);
      property(Abc, float, xyz);

      Abc()
         {
         def.owner = this;
         xyz.owner = this;
         $def = 0;
         $xyz = 3.14;
         }
      ~Abc() {}
   };


int main()
   {
   Abc   abc;

   // Access using variable notation

   cout << "abc.$def = " << abc.def << endl;
   abc.def = abc.def + 1;
   cout << "abc.$def = " << abc.def << endl;

   cout << endl;

   // Access using operator notation

   cout << "abc.$def = " << abc.def() << endl;
   abc.def(abc.def() + 1);
   cout << "abc.$def = " << abc.def() << endl;

   cout << endl;

   // Example of controlled access

   cout << "abc.$xyz = " << abc.xyz << endl;
   // The next line will cause a compile error
   // abc.xyz = abc.xyz + 1;
   cout << "abc.$xyz = " << abc.xyz << endl;

   return 0;
   }

=====================================================

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]