Jason D. Morris wrote:
>
> On 29 Mar 1996 09:07:43 PST, davidb@datalytics.com (David Bradley)
> wrote:
>
> >Lastly the naming of the data member/accessors breaks most common
> >styles.  Usually the member functions are distingiushed in some manner
> >from the data members.
>
> If you mean not explicitly naming the get/set functions with get/set
> tacked on the beginning of the name then yes, I agree that the
> property template breaks with common style.  Personally, I never use
> get/set prefixes in any of the code that I write.  When I do have
> members that perform get/set operations I overload member function
> acessors with names like those used by the property class.  Client
> code should never rely on any internal class implementation details;
> only interfaces to the services provided by the class.
>

Consider a naming convention in which dms are prefixed with
"m_."  In that case, public dms would have names like "m_Data,"
while the corresponding accessor/modifier mfs would be named
"Data."  Only when dms are named the same way as mfs would there
be no problem recognizing that you just add parentheses to the
dm name.

--
Robert Stewart  | My opinions are usually my own.
Datalytics, Inc. | stew@datalytics.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>C++ is an OO language, and of course supports encapsulation.
>Problem is - there is no standard way to add access methods.
>For example:
>class foo
>{
>public:
> SetMember( Type aMember );
> Type Member( );
>private:
> Type Member;
>};

#ifndef PROPERTY_H__
#define PROPERTY_H__

// The property class controls access to a captive variable.
// It captures the get/set pattern.  This class first appeared
// in the November/December 1995 Vol. 7 / No. 9 Issue of C++ Report
// in the article Patterns in Practice: A property template for C++
// by Colin Hastie.

template < class T >
class property
{
private:
    T content;  // captive variable

    // non-implemented non-accessible assignment operator
    void operator =( const property< T >& );

public:
    // ctors
    property() {}
    property< T >( const T& t )
        : content( t )
    {}

    // accessors
    T operator()() const   // get
    { return content; }

    void operator()( const T& t )  // set
    { content = t; }
};

#endif


To use this class you'd do something like this...

class foo
{
public:
    property< int > foo_number;
};
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Marueli Sunny (sunny@libra.math.tau.ac.il) wrote:
: class foo
: {
: private:
:  Type Member : read GetMember, write SetMember;
: };

I'm not sure of the point of this syntax, but either way it would be too
limiting. Something that comes up often is where the get method ought
to be public, but the set method shouldn't.

So, we'd have to change the syntax to:
class foo
{
private:
      Type Member : public read GetMember, protected write SetMember;
};

or, since we want to split interface (public or protected) from the internals
we'd want GetMember in the public section, and SetMember in the protected
section, perhaps with syntax like this:
class foo
{
public:
    Type GetMember : read Member;
protected:
    void SetMember : write Member;
}

Member could be either declared, or figured out as a private member of
type Type. But is this really any better than
class foo {
public:
    Type GetMember { return Member; }
protected:
    void SetMember(const Type& m) { Member = m; }
private:
    Type Member;
}

BTW, I prefer using Type member() and void member(const Type&) as a naming
convention for access functions. Less verbose, but just as clear.


Perhaps a suggestion would have been to allow member v'bles to have a
pair of access modifiers, and allow automatically generated access functions
have each of the pair. For example
class foo
{
public read, protected write:
    Type Member;
}

which automatically generates a v'ble and two access function all of the same
name. The fact that the three have different manglings saves the linker from
ambiguity, and the lack of prototype vs. two different prototypes clears up
compiler issues.
Actually, such a system could force all member variable private, always
generate access functions. We could just take "public:" as shorthand for
"public read, public write:", etc...

Interesting feature, won't happen.


--
Micha Berger 201 916-0287        Help free Ron Arad, held by Syria 3255 days!
AishDas@haven.ios.com                     (16-Oct-86 -  5-Oct-95)
<a href=news:alt.religion.aishdas>Orthodox Judaism: Torah, Avodah, Chessed</a>
<a href=http://haven.ios.com/~aishdas>AishDas Society's Home Page</a>
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jdmorris@ix.netcom.com (Jason D. Morris) wrote:

>#ifndef PROPERTY_H__
>#define PROPERTY_H__
>
>// The property class controls access to a captive variable.
>// It captures the get/set pattern.  This class first appeared
>// in the November/December 1995 Vol. 7 / No. 9 Issue of C++ Report
>// in the article Patterns in Practice: A property template for C++
>// by Colin Hastie.
>
>template < class T >
>class property
>{
>private:
>    T content;  // captive variable
>
>    // non-implemented non-accessible assignment operator
>    void operator =( const property< T >& );
>
>public:
>    // ctors
>    property() {}
>    property< T >( const T& t )
>        : content( t )
>    {}
>
>    // accessors
>    T operator()() const   // get
>    { return content; }
>
>    void operator()( const T& t )  // set
>    { content = t; }
>};
>
>#endif
>
>
>To use this class you'd do something like this...
>
>class foo
>{
>public:
>    property< int > foo_number;
>};

On the surface this sounds good.  The obvious problem is the issue of
access.  You may want the a private set and public get.

Another problem is you are unable to perform any validation within the
set function.

Lastly the naming of the data member/accessors breaks most common
styles.  Usually the member functions are distingiushed in some manner
from the data members.

===============================================
DISCLAIMER: I may be a member of humanity,
but I'm not a spokesman for humanity.
 davidb@datalytics.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

On 29 Mar 1996 09:07:43 PST, davidb@datalytics.com (David Bradley)
wrote:

>On the surface this sounds good.  The obvious problem is the issue of
>access.  You may want the a private set and public get.

>Another problem is you are unable to perform any validation within the
>set function.

The property class was designed to caputure the "get/set" pattern for
simple value types that need no validation.  In his article, the
author explains that the idea originated with Delphi properties.  It
posted this class in response to a discussion regarding adding
extensions to C++ to allow read/write access to member variables.
Basically, I wanted to point out that using a simple template class
you could accomplish the same thing the proposed extensions would
accomplish.  If you only wanted a public get, you could take the
property template and create a new version called read_only_property
in which the set member not provided.  I think that most of us would
agree that public data members are a bad thing and that acessing them
through function calls allows us to later change how the data members
are represented with out affecting client code.

>Lastly the naming of the data member/accessors breaks most common
>styles.  Usually the member functions are distingiushed in some manner
>from the data members.

If you mean not explicitly naming the get/set functions with get/set
tacked on the beginning of the name then yes, I agree that the
property template breaks with common style.  Personally, I never use
get/set prefixes in any of the code that I write.  When I do have
members that perform get/set operations I overload member function
acessors with names like those used by the property class.  Client
code should never rely on any internal class implementation details;
only interfaces to the services provided by the class.


Jason
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hello.

C++ is an OO language, and of course supports encapsulation.
Problem is - there is no standard way to add access methods.
For example:
class foo
{
public:
 SetMember( Type aMember );
 Type Member( );
private:
 Type Member;
};

Now, this code is reasonable, but it could be better:
[ I really don't know where I'm stealing this syntax. Sorry, anyway ]

class foo
{
private:
 Type Member : read GetMember, write SetMember;
};

and then you can do something like:
foo x;
x.Member = 5; // Calls SetMember()
cout << x.Member; // Calls GetMember()


I think this kind of code is much more elegant, and forces the use of
access methods, which isn't bad by itself.

------------

   Sunny
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]