Maybe what we need is not an access specifier, but a new
function-specifier (Like static, virtual, etc). An associated member
function would be a perfectly normal member function ( scope, this
pointer, etc), the only exception being that it cannot access private
and protected members of its class and base class(es). Consequently,
we could have private associated, protected associated, and public
associated functions. The priv/prot/pub would say who can access the
function, and the "associated" would say what the *function itself*
can access.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
To iterate is human, to recurse divine.
-L. Peter Deutsch
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Prateek R Karandikar wrote:

> Maybe what we need is not an access specifier, but a new
> function-specifier (Like static, virtual, etc). An associated member
> function would be a perfectly normal member function ( scope, this
> pointer, etc), the only exception being that it cannot access private
> and protected members of its class and base class(es). Consequently,
> we could have private associated, protected associated, and public
> associated functions. The priv/prot/pub would say who can access the
> function, and the "associated" would say what the *function itself*
> can access.

I don't really like having this information as a part of the function
declaration (i.e.: interface) as it only affects the function
implementation. I also don't get the usefulness of this feature, maybe
you could provide a use case.

Alberto

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> I don't really like having this information as a part of the function
> declaration (i.e.: interface) as it only affects the function
> implementation. I also don't get the usefulness of this feature, maybe
> you could provide a use case.
>
> Alberto

If a member function doesn't need private access, why give it access?
If we explicitly state that the function doesn't need access, the
compiler could help in checking our errors. When redesigning the
implementation of a class (without affecting the interface), we have
to look at all function that have access. If, while redesigning the
implementation, we see that a function is associated, we know that it
has access only to the public interface, which we aren't changing
anyway. So the number of functions we have to consider during the
redesign reduces. Why is having access an inherent property of
members?

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
To iterate is human, to recurse divine.
-L. Peter Deutsch
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:
> If the functions could be bound to the class(es) they are associated with,
> there would be more clarity in their purpose, refactoring would be easier,
> namespaces would be more orderly, IDE's could provide more complete
> information about the facilities associated with a given class, etc.

Correct me if I'm wrong, but all those reasons seems related only to
documentation and to automated source code parsing/handling and have no
real impact on code semantic. Therefore, I don't see why you want to
introduce a new keyword when a specially formatted comment (a la
JavaDoc, for instance) could achieve the same result just as easily and
without changing the language. By the way, the idea of using comments to
keep this kind of information is already being used by several
commercial CASE packages.

Alberto Barbati

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In another context I proposed the introduction of a new access specifier.
The word I used was /associated/.  The intended meaning is that
an /associated/ member is inextricably connected to the class, but does not
have reason or ability to access private or protected members.  My
motivation was to find a compromise between my desire for
compartmentalization, and Stroustrup's reasoning that some 'helper'
functions don't need private or protected access to class members. The
following from TC++PL(SE) explains the reasoning:

"Typically, a class has a number of functions associated with it that need
not be defined  in the class itself because they don't need direct access
to the representation. For example:

  int dif(Date a, Date b); // number of days in the range [a,b) or [b,a)
  bool leapyear(int y);
  Date next_weekday(Date d);
  Date next_Saturday(Date d);

"Defining such functions in the class itself would complicate the class
interface and increase the number of functions that would potentially need
to be examined when a change to the representation was considered.

"How are such functions "associated" with the class /Date/? Traditionally,
their declarations were simply placed in the same file as the declaration
of class Date, and users who need /Date/s would make them all available by
including the file that defined the interface (9.2.1). For example:

#include "Date.h"

"In additions to using a specific Date.h header, or as an alternative, we
can make the association explicit by enclosing the class and its helper
functions in a namespace:

  namespace Khrono{ // facilities for dealing with time
    class Date{/*...*/};
    int dif(Date a, Date b); // number of days in the range [a,b) or [b,a)
    bool leapyear(int y);
    Date next_weekday(Date d);
    Date next_Saturday(Date d);
    //...
  }

"The Khrono namespace would naturally also contain related classes, such as
Time and Stopwatch, and their helper functions."
//-----------------------------------------//

To my mind the argument regarding the complexity of the interface is
misplaced.  Now we have a namespace with an 'interface' which has classes
and functions.  Some of the functions may or may not be related to Date or
other classes.  If we wish to extract Date, or some other class, from the
namespace, we are again revisited by the problem of considering which
functions are involved.

If the functions could be bound to the class(es) they are associated with,
there would be more clarity in their purpose, refactoring would be easier,
namespaces would be more orderly, IDE's could provide more complete
information about the facilities associated with a given class, etc.

It was for this reason I proposed the /associated/ access specifier.  The
more I think about this, the more reasonable it seems to me.  There are
many unanswered questions such as how they would be inherited, whether they
would all be static (if that matters), etc.

I'm interested to know what other's think about this idea.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]