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

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

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 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 ha=
ve not=20
|> seen mentioned here yet.  That is, public const pointers:
|>=20
|> 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 =3D &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=FCnemann
 #,  \  Fakult=E4t f=FCr Informatik, Technische Universit=E4t M=FCnchen=
, Germany.
  |   > email: schuenem@informatik.tu-muenchen.de
  v=3D-<  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. ]

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

>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 {
>  private:
>  int readOnly;
>  public:
>  static const int Thing::*ReadOnly =Thing::&readOnly;
>  };
>  Thing t;

Since readOnly is volatile, it seems wrong for *ReadOnly to be static.

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

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

It is long winded only because you made ReadOnly static.

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

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

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

Friends are not always evil, but this one is.  ;-)

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

I don't see what this accomplishes if static members have normal class
accesses, as discussed above.

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

Well, I thought (1) was already true, based on perhaps my mis-reading of
Stroustrup.  Or maybe the standard changed?

I do not see much value to (2), other than making C++ that much more
complicated and thereby enhancing our job security.  :-)

------------------------------------------------------------------
 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 <45d5r1$fk4@mujibur.inmind.com>, mfinney@inmind.com says...
>
>I have considered this issue for an extension of C++ (as a new language).

Me too. But in my case it was a number of years ago - before C++. And I did
not
know about C - I based my ideas on my own experiance with somthing simmolag
to
OOP based mostly on macroassembler (IBM360/370) and what I read about
Simula-67.

>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.
>   ...... snip ......
>
>Any comments?

  About read interface: as I understand you are suggesting use syntax x() for
both variables and functions just because othervise it will break existing
C/C++ code. I understand reason, but I am afraid that will make code less
understandable.

  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?

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

MTM4@rsvl.unisys.com (Mike McCormick) writes:

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

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.

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


---
[ 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 McCo
rmick) 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. ]

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:

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

I think you don't need a language extension to do this:

  #include <iostream.h>

  template <class T> class RW {
  public:
    virtual operator T () const = 0;
    virtual void operator= (const T&) = 0;
  };

  class MyInt: public RW<int> {
    int val;
  public:
    MyInt (int x = 0): val (x) {}
    operator int () const { cout << "Reading" << endl; return val; }
    void operator= (const int& x) { cout << "Writing" << endl; val = x; }
  };

  int main () {
    MyInt i (3);
    i = 4;
    return i;
  }

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

Hello.
     The proposal is a new class access specifier with the
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.


Implementation.
     I think that the compiler overhead for this new feature
will be little.


Sorry in advance for my bad English.

Un cordial saludo.

Juan Carlos Rodriguez Del Pino
Departamento de Informatica y Sistemas
Universidad de Las Palmas de Gran Canaria
Canary Islands, Spain

http://protos.dis.ulpgc.es/~jcrodrig
---
[ 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. ]

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