🚀 go-pugleaf

Let's try it another way, using memberpointers (- it woun't not easy)!
We'd like the call to look like `t.*ReadOnly'
which is similar to Mike McCormick's `*(t.pReadOnly)'
[Hope the memberpointer-syntax is ok].

  class Thing {
	...
  public:
  static const int	Thing::*ReadOnly = Thing::&readOnly;
  };
  Thing	t;

  t.*ReadOnly;
This doesn't work, coz ReadOnly is unknown outside Thing!

  t.*Thing::ReadOnly;
This works, but is too long winded.

  using Thing::ReadOnly;
This doesn't work, coz a class is not a namespace.

  const int	Thing::*ReadOnly = Thing::&readOnly;
Defining the memptr outside the class doesn't work
coz Thing::readOnly not accessable (private).

  class Thing {
	...
  public:
  friend void	f ();
  };
  void f ()
  {	const int	Thing::*ReadOnly = Thing::&readOnly;
	t.*ReadOnly;
  }
This works, but making a whole funktion friend of the class
violates encapsulation.

  class Thing {
	...
  public:
  friend const int	Thing::*ReadOnly;
  };
  const int	Thing::*ReadOnly = Thing::&readOnly;
This doesn't work, coz a variable can't be a friend.

Conclusion: We can get quite near to what we want. With a
slight change in the language we could get `t.*ReadOnly':
(1) Either regard a class as a namespace for it's static members.
(2) Or allow variables to be declared as friends, so that
    the initialization-expression of this variable has friend-access.

I like both as IMHO they make the language cleaner, more orthogonal.
#1 has already been discussed in this newsgroup - with few support.
#2 is a new(?) idea. Compared to merging classes and namespaces
the required change is smaller and less influent. With public
support #2 could make it (my $.02).


Ulf Schuenemann

--------------------------------------------------------------------
  ,_.   Ulf Schünemann
 #,  \  Fakultät für Informatik, Technische Universität München, Germany.
  |   > email: schuenem@informatik.tu-muenchen.de
  v=-<  WWW:   http://hphalle2.informatik.tu-muenchen.de/~schuenem/
        ...there is only one way to "skin a C+@"...:)  -- Jim Fleming

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]