🚀 go-pugleaf

"Juan Carlos Rodriguez" <JUANCA@sergied.dis.ulpgc.es> writes:
	...
>following characteristics:
>1) Its keyword will be "publiconst".
>2) For the own class and its friends the attributes affected
>   acts as regular "public".
>3) For the rest, the attributes are seems as "const".
>4) The "publiconst" functions are as "public".

>Improve.
>     The new access way will eliminate the tedious work of
>write functions to protect the external access to interesting
>class attributes.

The probability of such a large change being adopted at this stage is
as close to zero as it matters, of course, making it all academic, but
I think it worth discussing why it would be a bad idea, anyway...

Providing access functions to class attributes is a particular style,
and generally _not_ a particularly good one -- in my experience, it
tends to result from under-design.  Why does everybody need read access
to those attributes -- why are the attributes in the class
_interface_?  Sure, there _are_ cases in which a property of an object
that its clients will want to query happens to be best _implemented_ as
a data member of the object's class, but how frequent is such a
_coincidence_?  Surely not frequent enough, in good OO design style, to
make it _tedious_ to provide the accessor explicitly in those special
cases!  Overabundance of accessors may indicate that the class, instead
of having been _designed_ as an abstraction of something, was built
"from the implementation up" -- i.e., underdesigned.  _Encouraging_
such underdesign, by providing special syntax to remove the tedium
connected to it, hardly seems to be a worthwhile goal...


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120


---
[ 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. ]

martelli@cadlab.cadlab.it (Alex Martelli) wrote:

>"Juan Carlos Rodriguez" <JUANCA@sergied.dis.ulpgc.es> writes:

>>     The new access way will eliminate the tedious work of
>>write functions to protect the external access to interesting
>>class attributes.

>Providing access functions to class attributes is a particular style,
>and generally _not_ a particularly good one -- in my experience, it
>tends to result from under-design.  Why does everybody need read access
>to those attributes -- why are the attributes in the class
>_interface_?  Sure, there _are_ cases in which a property of an object
>that its clients will want to query happens to be best _implemented_ as
>a data member of the object's class, but how frequent is such a
>_coincidence_?  Surely not frequent enough, in good OO design style, to
>make it _tedious_ to provide the accessor explicitly in those special
>cases!

I am a little uneasy with the idea that a reasonable design technique should be
tedious to discourage its overuse.  However, I don't think that the problem
mentioned is bad enough to add another keyword.  But if the problem were severe
enough to merit a language change, I think there is a better approach.

The ideal would be to eliminate altogether accessor functions from the class
interface.  Whether an attribute of a class is implemented as a variable or a
function is not important to the source interface.  Instead, there would simply
be attributes, which could be accessed (i.e. square.Area).  Whether these were
implemented as a data member or as a function (i.e. { return height * width; })
is not particularly relevent to the caller, so why should he specify "Area()"
rather than simply "Area".

P.S. I am not certain that I am using the best terminology here.  If anyone
knows of more "official" terminology, I would like to hear it.  When I say
"source interface", I mean the way the caller accesses an attribute in the
source code.  This is distinguished from the "object interface", which is the
way that the compiled object code accesses the attribute.  In the "Area"
example above, changing an attribute from a data member to a function changes
the object interface without changing the source interface.  I current systems,
this would require a recompile, but would not require any source changes.

John McGrath



---
[ 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. ]

Something I would like to see that would require a MAJOR enhancement to C++
(read: would go into the next ANSI spec at the earliest) would be the
ability to define storage classes. This would make the memory allocation
and or method invocation scheme orthogonal to the object's class.

Places where I'd want to use it would be for implementing object
persistance, remote objects, mapping to relational dBs, objects with
mutex semaphores around them for parallel threads, etc...

--
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.  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. ]

I concur that "get methods" are tedious, and (unfortunately) ubiquitous.

However, there is an alternative to changing the standard which I have not 
seen mentioned here yet.  That is, public const pointers:

class Thing :
	pReadOnly(&readOnly)
{
private:
	int readOnly;
public:
	const int* const pReadOnly;
};

In this class, readOnly is effectively a public-but-read-only attribute, 
thanks to the public pointer pReadOnly.  Outside Thing, readOnly can be read 
directly via *Thing.pReadOnly ... but pReadOnly and *pReadOnly are both 
protected from updates.


------------------------------------------------------------------
 Mike McCormick
 mtm4@rsvl.unisys.com
 m.mccormick2@genie.geis.com
------------------------------------------------------------------
 While you're out surfing the internet...
 I'm back on the beach blowing my little lifeguard whistle.
------------------------------------------------------------------

[ 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. ]

In article <44spqj$j37@nn.fast.net>, 
jpm@nscs.fast.net (John McGrath)says...
>  ......
>The ideal would be to eliminate altogether accessor functions from the
>class interface.  Whether an attribute of a class is implemented as a
>variable or a function is not important to the source interface.
>Instead, there would simply be attributes, which could be accessed
>(i.e. square.Area).  Whether these were implemented as a data member or
>as a function (i.e. { return height * width; }) is not particularly
>relevent to the caller, so why should he specify "Area()" rather than
>simply "Area".

It is so close to my ideal. But I have one addition. You described "abstract 
read source interface". I would like to have also "write interface": to let 
caller write just "square.Area = 10;" instead of "square.Change_Area(10)".

-----------------------------------------------------------------------------
-------
Michael Furman,                                   (603)893-1109
Geophysical Survey Systems, Inc.              fax:(603)889-3984
13 Klein Drive - P.O. Box 97                      engr@gssi.mv.com 
North Salem, NH 03073-0097                        71543.1334@compuserve.com
-----------------------------------------------------------------------------
-------
---
[ 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. ]

In <DG6q6J.EEt@mv.mv.com>, ENGR@GSSI.MV.COM (Michael Furman) writes:
>It is so close to my ideal. But I have one addition. You described "abstract 
>read source interface". I would like to have also "write interface": to let 
>caller write just "square.Area = 10;" instead of "square.Change_Area(10)".

I have considered this issue for an extension of C++ (as a new language).
You might find my notes interesting...

"If we have the declaration...

   int abc();

Then abc is a function taking no parameters and returning an
int.  To call the function, it is necessary to write...

   abc()

and to take the address of the function, it is necessary to
write either...

   abc

or ...

   &abc

It would be VERY convenient to be able to call the function
by writing

    abc

but that would break too much C++ code.

The problem is that it is desirable to make all attribute
accesses use the same syntax.  Therefore...

If we have the class definition...

   class Abc
      {
      int x;
      int y();
      int z(int a);
      };

   Abc   abc;

Then the members of the class may be accessed by...

   abc.x();
   abc.y();
   abc.z(1);

The same form can be used when "abc." may be omitted as in a
member function.  However, the more conventional form...

   abc.x

can still be used, but will produce a warning message about
obsolete syntax.  This warning message can be disabled by the
user.  Further, referencing "abc.z" will return the address of
the member function z as a pointer to member, but will also
produce a warning message about obsolete syntax (which can also
be disabled).

Further, if it is desired to change the value of x, then

   abc.x = 1;

can be used, but will produce a warning message about obsolete
syntax except in member functions.  Again, this warning message
can be disabled.  The preferred method is to overload the definition
of x, for example...

   class Abc
      {
      int x;
      int x(int a) {x = a;}
      int y();
      int z(int a);
      };

   Abc   abc;

and then the syntax...

   abc.x(1);

can be used.  Since it is illegal to assign to a function (for
example...

   abc.z = 1;

is illegal in C++), the assignment "x = a;" can be handled correctly."

Any comments?


Michael Lee Finney


[ 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. ]

In article <MTM4.1214.010BD7A3@rsvl.unisys.com>, MTM4@rsvl.unisys.com (Mike McCormick) writes:
|> However, there is an alternative to changing the standard which I have not 
|> seen mentioned here yet.  That is, public const pointers:
|> 
|> class Thing :
|> 	pReadOnly(&readOnly)
        ^^^^^^^^^^^^^^^^^^^^ - you mixed class and ctor.
|> {
|> private:
|> 	int readOnly;
|> public:
|> 	const int* const pReadOnly;
|> };

Unfortunatly, now every instance gets an additional pointer.
If one could declare, that every ctor of Thing initializes
pReadOnly the same way so that for every instance pReadOnly
points to the same attribute, then pReadOnly could be optimized
away (like global const).

This is an example where it would be usefull to be able to initialize
not only static but also nonstatic datamembers inside the class defn.

  class Thing {
  private:
	int readOnly;
  public:
	const int* const pReadOnly = &readOnly; // ILLEGAL
  };

[ Regarding how hard it was to introduce this for static members
it seems unlikely to be allowed for nonstatic members. ]


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/

[ 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. ]

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. ]

>From: schuenem@informatik.tu-muenchen.de (Ulf Schuenemann)
>Subject: Re: Proposal for a new access specifier
>Date: 10 Oct 1995 18:49:35 GMT

>Mike McCormick) writes:
>|> However, there is an alternative to changing the standard which I have
>|>not seen mentioned here yet.  That is, public const pointers:
>|> class Thing :
>|>      pReadOnly(&readOnly)
>        ^^^^^^^^^^^^^^^^^^^^ - you mixed class and ctor.
>|> [snip]

Oops!  The correct rendition would be:

class Thing:
{
private:
	int readOnly;
public:
	const int* const pReadOnly;
	Thing();
};

Thing::Thing() : pReadOnly(&readOnly) {};

>Unfortunately, now every instance gets an additional pointer.
>If one could declare, that every ctor of Thing initializes
>pReadOnly the same way so that for every instance pReadOnly
>points to the same attribute, then pReadOnly could be optimized
>away (like global const).

I probably misunderstand, but this sounds like an issue only if readOnly is 
static.  Since it is not, every Thing instance has its own readOnly, so every 
instance must have pReadOnly also.

>This is an example where it would be usefull to be able to initialize
>not only static but also nonstatic datamembers inside the class defn.

>  class Thing {
>  private:
>        int readOnly;
>  public:
>        const int* const pReadOnly =&readOnly; // ILLEGAL
>  };

Just supposing this *were* legal syntax, how is it an improvement over the 
constructor initializer syntax?



------------------------------------------------------------------
 Mike McCormick
 mtm4@rsvl.unisys.com
 m.mccormick2@genie.geis.com
------------------------------------------------------------------
 While you're out surfing the internet...
 I'm back on the beach blowing my little lifeguard whistle.
------------------------------------------------------------------

[ 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. ]

In article <MTM4.1250.01029391@rsvl.unisys.com> MTM4@rsvl.unisys.com (Mike McCormick) writes:

>>This is an example where it would be usefull to be able to initialize
>>not only static but also nonstatic datamembers inside the class defn.
>>
>>  class Thing {
>>  private:
>>        int readOnly;
>>  public:
>>        const int* const pReadOnly =&readOnly; // ILLEGAL
>>  };
> 
> Just supposing this *were* legal syntax, how is it an improvement over the 
> constructor initializer syntax?

If it were legal, pReadOnly need not take any space in the class becuase
the compiler would always know where it pointed.  Just like `const int
&const pReadOnly = &readOnly;' might do if legal.

With constructor initializer syntax, the compiler can only know where
pReadOnly points if the constructor is inlined.
-- 
Regards,

Hallvard

[ 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. ]

h.b.furuseth@usit.uio.no (Hallvard B Furuseth) writes:

>MTM4@rsvl.unisys.com (Mike McCormick) writes:
>
>>>This is an example where it would be usefull to be able to initialize
>>>not only static but also nonstatic datamembers inside the class defn.
>>>
>>>  class Thing {
>>>  private:
>>>        int readOnly;
>>>  public:
>>>        const int* const pReadOnly =&readOnly; // ILLEGAL
>>>  };
>> 
>> Just supposing this *were* legal syntax, how is it an improvement over the 
>> constructor initializer syntax?
>
>If it were legal, pReadOnly need not take any space in the class becuase
>the compiler would always know where it pointed. 

No, that's not true.  The compiler would still have to reserve space
in the class for `pReadOnly', because you can take its address.

>Just like `const int &const pReadOnly = &readOnly;' might do if legal.
	      (You mean `... rReadOnly = readOnly;'.)

A compiler could do this optimization for references, like the above,
since you can't take the address of a reference.
But the optimization would not be valid for pointers.

-- 
Fergus Henderson             |  "Australia is the richest country in the world,
fjh@cs.mu.oz.au              |   according to a new system of measuring wealth
http://www.cs.mu.oz.au/~fjh  |   announced by the World Bank yesterday."
PGP: finger fjh@128.250.37.3 |  - Melbourne newspaper "The Age", 18 Sept 1995.


---
[ 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. ]

ENGR@GSSI.MV.COM (Michael Furman) writes:
	...
>>Instead, there would simply be attributes, which could be accessed
>>(i.e. square.Area).  Whether these were implemented as a data member or
>>as a function (i.e. { return height * width; }) is not particularly
>>relevent to the caller, so why should he specify "Area()" rather than
>>simply "Area".

>It is so close to my ideal. But I have one addition. You described "abstract 
>read source interface". I would like to have also "write interface": to let 
>caller write just "square.Area = 10;" instead of "square.Change_Area(10)".

To paraphrase Dennis Ritchie: "If you want Sather, you know where to find
it...!":-).  (If you _don't_ know: ftp.icsi.berkeley.edu, /pub/sather).

To explain: it is of course unthinkable that changes of this magnitude
would be adopted in the standard as late as NOW.  And a good thing, too!
C++ cannot and should not be all things to all people -- it's arguably
even too large as it stands; and it's unarguably high time for a STABLE
standard for it.

Other languages (excellent ones, too) are exploring and will further
explore every conceivable corner of the language-design space.  Sather,
in particular, among many other ideas, implements exactly this sort of
syntactic sugar; if it's really that important to you, I _do_ stronly
suggest you try it out.  (Personally, it's one of their few choices
that I _dis_like, so, I'm _quite_ happy that C++ doesn't have it:-).


Alex


---
[ 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. ]

In article <DGEovz.DKv@mv.mv.com> ENGR@GSSI.MV.COM (Michael Furman) writes:

[ snip ]
     I can explain what I would suggest (trying to invent C/C++ compatible 
   syntax on fly). I do not want to change access syntax at all but use 
   additional 
   specifier to variable declaration / definition. It is "access type" that can 
   be:

     1. Memory (default): regular C/C++ variable that will be mapped to some 
   memory.
     2. Emitter: in this case you must specify access function to call when 
   somebody
	will read value of this "variable".
     3. Collector: in this case you must specify access function to call when 
	somebody will write value of this "variable".

   (I am not sure about words emitter and collector. And I am sorry about my 
   English)

   Declaration of some class may look like:

      class X
	{
      private:
	int x_;
      public:
	int emitter x {return x_;}
	collector x(int &arg) {x_ = arg;}
	}

   or, may be:

	class Y
	  {
	public:
	  int emitter x {int t; scanf("%d", &t); return t;}
	  collector x(int &arg) { printf("%d\n", arg); }
	  }

   I think it does not break any existent code (but needs two or even three 
   extra reserved words).

   Any comments?

This capability is already in the language, there are no changes
needed to create it.  There is though the need for a realization that
you need a seperate type for your variable. 

Your example then becomes
	class Y
	  {
	public:
	  operator int () { int t; cin t; return t;}
	  int operator = (int arg) { cout << arg; return arg; }
	  }

So, there isn't a need for a change to allow the capability you want.
On the other hand there might be call for a standard template class
that can implement semantics like read only or write only.

Example:
template <class T>
class write_only {
private:
  T & ob;  // There's no way to read T;
public:
  read_only(T & obj) : ob(obj) {}
  ~read_only() {}
  void operator = (const T & obj) { ob = obj; }
}

Now it would be useful for a write only variable if there were a
syntax for static references that allowed them to be optimized out,
and not need to be initialized in every constructor.


---
[ 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. ]

 ENGR@GSSI.MV.COM (Michael Furman) writes:
  ...
 >>Instead, there would simply be attributes, which could be accessed
 >>(i.e. square.Area).  Whether these were implemented as a data member or
 >>as a function (i.e. { return height * width; }) is not particularly
 >>relevent to the caller, so why should he specify "Area()" rather than
 >>simply "Area".

 >It is so close to my ideal. But I have one addition. You described "abstract 
 >read source interface". I would like to have also "write interface": to let 
 >caller write just "square.Area = 10;" instead of "square.Change_Area(10)".

But you can already do this.  Not across the board, but you can do it
if you want.  Just make each attribute a class of it's own.  You can
then overload operator = and operator int and say all of that.

You would probably want to make all of your attributes a class hiarchy
so that you could change their implementations, etc, etc. 

There is not a need to have this in the standard.
It's already there. (In a C++ way)

In article <m0t4Dmy-000glNC@axpblib> martelli@cadlab.it (Alex Martelli) writes:

   (Personally, it's one of their few choices
   that I _dis_like, so, I'm _quite_ happy that C++ doesn't have it:-).

But it does!


---
[ 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. ]

ENGR@GSSI.MV.COM (Michael Furman) writes:
	...
>  1. Memory (default): regular C/C++ variable that will be mapped to some 
>memory.
>  2. Emitter: in this case you must specify access function to call when 
>somebody
>     will read value of this "variable".
>  3. Collector: in this case you must specify access function to call when 
>     somebody will write value of this "variable".
	...
>I think it does not break any existent code (but needs two or even three 
>extra reserved words).

>Any comments?

Sather simplifies this sort of approach, in its "syntactic sugar
expression" syntax production, by mapping syntactic sugar to fixed
names.  For example, "a[row,col] := b;" always maps to "a.aset(row,col,b)",
just as "a/b" always maps to "a.div(b)", etc.  In particular, in Sather,
"a:=b" maps to "a(b)", and a plain identifier "b" maps to "b()".

A mapping to fixed names seem to me to be a superior approach to the
extra complications of a user-definable mapping, for something
ultimately as minor as syntactic sugar.  Note that the fixed names are
not reserved words -- they're plain old identifiers of methods that the
class author will have to declare and define normally, they are subject
to normal overload resolution, etc etc.  If the user would like
"a=b" to actually call "a.set(b.get())", while the fixed mapping
would give "a(b())", nothing stops him or her from coding two simple
inline forwarding functions in the appropriate classes:
	(in a's class) bar operator()(foo X) {return set(X);}
	(in b's class) foo operator()() {return get();}

You could implement this as an upwards-compatible extension to C++ (no
chance that it will make it into the standard -- but nothing stops you
from taking GNU C++ and hacking this extension into it, just as it
already has several extensions to both ANSI C, and proposed-ANSI
C++...  if you make it popular enough, it will have a chance to get in
by the time the _next_ round of the standardization process rolls in,
early next century).  To avoid breaking any existing code, just have
the sugar-mapping extension kick in only when, without it, the code
would be ill-formed by present C++ language rules -- in particular, you
will have to decide whether this is worth breaking the
visibility-vs-access rule of C++ -- I suggest you don't, but rather
treat it as one more candidate for function-call overloading (with
priority lower than existing forms, so as to make sure existing correct
programs stay the same).


Could we move this discussion to comp.LANG.c++...?  It really has
little or nothing to do with the language _standard_, per se...


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120

[ 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. ]

In article <EBIEDERM.95Oct16003412@cse.unl.edu>, ebiederm@cse.unl.edu says...
>  ..... snip .....
>This capability is already in the language, there are no changes
>needed to create it.  There is though the need for a realization that
>you need a seperate type for your variable.

There are a lot of ways to implement something that language does not 
support directly. I do not think that suggesting users to create number
of extra classes is a good thing.

>
>Your example then becomes
>        class Y
>          {
>        public:
>          operator int () { int t; cin t; return t;}
>          int operator = (int arg) { cout << arg; return arg; }
>          }

If I understood you correctly it is not my example but an extra code
needed each time to implement such capability.

>
>So, there isn't a need for a change to allow the capability you want.
>On the other hand there might be call for a standard template class
>that can implement semantics like read only or write only.

And I am not talking just about "read only" and "write only" variables,
but about "variables" that (their values) will be calculated at the read
access time or used for some immediate processing at the write access time.
I see it as extention of traditional variables - in such case "read 
calculation" is just reading from memory (for imbedded types - othervise
using "=" operator or copy constructor) and "write calculation" - writing
to memory.



-----------------------------------------------------------------------------
-------
Michael Furman,                                   (603)893-1109
Geophysical Survey Systems, Inc.              fax:(603)889-3984
13 Klein Drive - P.O. Box 97                      engr@gssi.mv.com 
North Salem, NH 03073-0097                        71543.1334@compuserve.com
-----------------------------------------------------------------------------
-------


[ 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. ]

In article <pu7n2almo7.fsf@themroc.colibri.de> hf@colibri.de (Harald Fuchs) writes:

>MTM4@rsvl.unisys.com (Mike McCormick) writes:
>> I probably misunderstand, but this sounds like an issue only if
>> readOnly is static.  Since it is not, every Thing instance has its
>> own readOnly, so every instance must have pReadOnly also.

>No, assuming pReadOnly always points to this->readOnly.  Since in this
>case the offset from "this" is fixed, and since every object has a
>(different) "this" anyway, you could treat pReadOnly as "this+offset"
>and thus optimize it away.

Okay, now I understand.  I must say however that I am uncomfortable with using 
static pointers to volatile members and relying on the compiler to always put 
things at the same offset within every instance.  OTOH I suppose the 
standard requires C++ compilers to do that?

>>> class Thing {>>> private:
>>> int readOnly;
>>> public:
>>> const int* const pReadOnly =&readOnly; // ILLEGAL
>>> };

>> Just supposing this *were* legal syntax, how is it an improvement over the 
>> constructor initializer syntax?

>A class might have _lots_ of different constructors.  It's "tedious and
>error-prone" (as Bjarne would say :-) to repeat thie initialization in
>all of them.

True.  This argument gets me partway toward overcoming my distaste for the 
static pointer to a volatile member too.  Thanks....

------------------------------------------------------------------
 Mike McCormick
 mtm4@rsvl.unisys.com
 m.mccormick2@genie.geis.com
------------------------------------------------------------------
 While you're out surfing the internet...
 I'm back on the beach blowing my little lifeguard whistle.
------------------------------------------------------------------

[ 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. ]

ebiederm@cse.unl.edu (Eric Biederman) writes:
	...
> >It is so close to my ideal. But I have one addition. You described "abstract
 
> >read source interface". I would like to have also "write interface": to let 

> >caller write just "square.Area = 10;" instead of "square.Change_Area(10)".

>But you can already do this.  Not across the board, but you can do it
>if you want.  Just make each attribute a class of it's own.  You can
>then overload operator = and operator int and say all of that.
	...
>In article <m0t4Dmy-000glNC@axpblib> martelli@cadlab.it (Alex Martelli) writes
:

>   (Personally, it's one of their few choices
>   that I _dis_like, so, I'm _quite_ happy that C++ doesn't have it:-).

>But it does!

C++ does not have _systematized_ support for accessors and mutators, nor
systematic syntactic sugar therefor.  Yes, you _can_ build such accessors
and mutators explicitly (obviously), and you _can_ sugar them up (both on
a case-by-case basis, or more systematically with suitable templates) --
but these possibilities descend from more generalized features of the
language, they're not ad-hoc constructs for the specific purpose of
enabling this programming style.

I most definitely do NOT object to powerful building blocks which
(though possibly at the cost of quite a bit of stylistic convention and
boilerplate) can be combined to support programming styles and paradigms
I may or may not care for -- if I DID so object, I guess I might hate C++
as much the average crusaders for other OO languages appear to:-).
What I don't particularly care for in Sather (and Eiffel and CORBA
IDL, for that matter) is systematic, ad-hoc support for member
accessors and mutators -- I claim it can result in encouraging a
style which often stems from "under-designed" classes, classes not
``properly'' thought of as avatars of some abstract entity...


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120
---
[ 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. ]

In article <MTM4.1251.012CDE71@rsvl.unisys.com>,
MTM4@rsvl.unisys.com (Mike McCormick) writes:
[..]
|> Since readOnly is volatile, it seems wrong for *ReadOnly to be static.
                     ^^^^^^^^ - readOnly is nonstatic, nonconst,
                                nonvolatile and not mutable.

I forgot to make clear: I was looking for a way to avoid
that every instance gets an additional pointer (pReadOnly).
That's why I tried it with a static member.
To use a static member for access to nonstatic members,
Thing::ReadOnly is a memberpointer (memptr). Think of it as an
(static) offset into the object's dataspace (in the case of
memberDATApointer). A memptr of type (T C::*) can be applied to
any instance of class C using the .* (->*) syntax, yielding an
attribute of type T of this instance. Thus it is reasonable for
ReadOnly to be a static member of Thing (first try) or even
no member of Thing at all (second try).
--------------------------------------------------------------------
First try:

|> >  t.*ReadOnly;
|> >This doesn't work, coz ReadOnly is unknown outside Thing!
|>
|> It's not so much that ReadOnly is unknown outside Thing (after all, it is
|> public) but rather that static members must be qualified by their class name.

Oops, you're correct.

[..]
|> >  using Thing::ReadOnly;
|> >This doesn't work, coz a class is not a namespace.
|>
|> I thought this did work.  See Stroustrup 2nd edition r.3.3.1.2.

I'd like it to work, but unfortunately 7.3.3 [namespace.udecl],5
(all citations from the Committee Draft, public review) prohibits
this and gives an example with static and nonstatic datamembers.
--------------------------------------------------------------------
Second try:

|> >  const int     Thing::*ReadOnly =Thing::&readOnly;
|> >Defining the memptr outside the class doesn't work
|> >coz Thing::readOnly not accessable (private).
|>
|> I thought this worked too.  Stroustrup r.9.4 says static members have the
|> usual class accesses even though they are initialized in file scope.

Attention:

  const int     Thing::*ReadOnly = &Thing::readOnly;
                                   ^- here goes the &
This defines a variable of memberdatapointer type `const int Thing::*'
(see 8.3.3 [decl.mptr]). [ Definition of a datamember of type
`const int*' would look like (see 9.5.3 [class.static.data]):
  const int*    Thing::static_datat_member = ...; ]

[..]
|> >  class Thing {
|> >  friend const int      Thing::*ReadOnly;
|> >  };
|> >  const int     Thing::*ReadOnly = &Thing::readOnly;
                                       ^- here goes the &
So it would be nice to be able to allow such a nonmember variable
(here: global variable) access to private Thing::readOnly.
But this is not allowed, coz a variable can't be declared friend.
This is a hole in the language, IMHO.

Ulf Schuenemann

PS Sorry my answer's late, there were problems with MIME encoding.
--------------------------------------------------------------------
 ,_.   Ulf Schuenemann
#,  \  Fakultaet fuer Informatik, Technische Universitaet Muenchen, Germany.
 |   > email: schuenem@informatik.tu-muenchen.de
 v=-<  WWW:   http://hphalle2.informatik.tu-muenchen.de/~schuenem/

[ 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. ]