In article <JASON.94Aug9193620@deneb.cygnus.com>
 jason@cygnus.com (Jason Merrill) writes:

>   > Preceding the kw with % was just an example. My point was that if a
>   > parser can be written with c++'s infamous syntax, a way can be found
>   > to add a keyword such as "visible" -- which should be legal only
>   > within a class declaration.
>
>   Simple; just stick __ in front of it.  And after it, if you so desire.
>   gcc has bunches of keywords like that.
>
>   Anyway, I don't think that's the issue.  If you don't want people modifying
>   your representation directly, chances are you may change your
>   representation at some point, and then everyone using your readonly
>   variables is out of luck.  Accessor functions avoid this problem.  Is it so
>   horrible to add () in a few places?
>
>   Jason


I don't mind writing () when accessing data as much as cluttering
class declarations with trivial reader functions (which are nearly
always inline).  I agree that many times the representation should be
screened behind an interface, but a feature such as 'visible' would be
a convenience for simpler classes -- it's not mandatory.

Perhaps an alternative is for the compiler to instantiate default
readers much as default copy ctors/assignment operators. This would
solve the representation problem but it would seem to require a
standard naming convention for reader functions, since data and
functions are in the same namespace.




--
 Alan Calvitti
 Control Engineering, CWRU

 In article <rfgCu5pzJ.7Dt@netcom.com>
 rfg@netcom.com (Ronald F. Guilmette) writes:

>   >1)  New keywords may break existing code...
>
>   Right in one.
>
>   >... -- Then why not precede
>   >new kw's with characters which are not allowed in identifiers? For
>   >example: %visible. Surely that couldn't possibly make c++ harder to
>   >parse than it currently is.
>
>   Dear Sir,  did you somehow forget that `%' is an operator in both C and
>   C++?

Preceding the kw with % was just an example. My point was that if a
parser can be written with c++'s infamous syntax, a way can be found
to add a keyword such as "visible" -- which should be legal only
within a class declaration.

>   Have you built a parser for C++ lately?

C -- as an joke, but I found it too hard. Subsequently I kept
modifying the syntax to make it easier to parse, but kept ending up
with lisp.


--
 Alan Calvitti
 Control Engineering, CWRU

>>>>> Alan Calvitti <calvitti@cthulhu.ces.cwru.edu> writes:

> Preceding the kw with % was just an example. My point was that if a
> parser can be written with c++'s infamous syntax, a way can be found
> to add a keyword such as "visible" -- which should be legal only
> within a class declaration.

Simple; just stick __ in front of it.  And after it, if you so desire.
gcc has bunches of keywords like that.

Anyway, I don't think that's the issue.  If you don't want people modifying
your representation directly, chances are you may change your
representation at some point, and then everyone using your readonly
variables is out of luck.  Accessor functions avoid this problem.  Is it so
horrible to add () in a few places?

Jason

In article <CALVITTI.94Aug1113952@cthulhu.ces.cwru.edu> calvitti@cthulhu.ces.cwru.edu (Alan Calvitti) writes:
>
>Amen. Those involved in the standardization of c++ seem reluctant to
>define new keywords, because:
>
>1)  New keywords may break existing code...

Right in one.

>... -- Then why not precede
>new kw's with characters which are not allowed in identifiers? For
>example: %visible. Surely that couldn't possibly make c++ harder to
>parse than it currently is.

(That's what I love about comp.std.c++.  No qualifications are required.
They let anybody in here. :-)

Dear Sir,  did you somehow forget that `%' is an operator in both C and
C++?

Have you built a parser for C++ lately?

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

   In article <31fato$blm@panix.com> tbak@panix.com (Thomas Bak) writes:

>   : >    (sound of fanfare)  readonly
>
>   : >   What do you think??
>
>   : Not a bad idea, but not necessarily a good idea either.  The original
>   : "readonly" keyword later evolved into the "const" keyword, but
>   : unfortunately this is not the same thing.
>
>   Maybe a better keyword would be 'visible'. I don't see any technical
>   problem with implementing such a keyword.
>
>   It is probably time for a major overhaul in C keyword use. When looking
>   at the many uses that some keywords have, one thinks it's time to improve.
>   Ex: 'static'.. Can anybody count how many uses 'static' has? And how
>   different their meanings are?

Amen. Those involved in the standardization of c++ seem reluctant to
define new keywords, because:

1)  New keywords may break existing code. -- Then why not precede
new kw's with characters which are not allowed in identifiers? For
example: %visible. Surely that couldn't possibly make c++ harder to
parse than it currently is.

2) Somehow, new kw's are perceived as adding complexity to the
language, and so they must be bad. -- Has anyone thought that keywords
providing a set of orthogonal features might actually render c++ more
readable and c++ code shorter?
 For instance, a 'visible' keyword would be a great addition to
the language in the 9x% of cases where member data is to be accessed
through a trivial reader.  Yes, I know, instead, of a public reader,
define a public const reference to the member; but then the reference
has to be initialized (either in one or more ctors or in yet another
utility function), plus the programmer has to keep in mind two
identifiers.  What's the point? Wasn't one of the aims of c++ to make
the programmer's job more fun?

--
+-----------------------------------+
|           Alan Calvitti           |
|  Systems and Control Engineering  |
|          CWRU, Cleveland          |
+-----------------------------------+

: >    (sound of fanfare)  readonly

: >   What do you think??

: Not a bad idea, but not necessarily a good idea either.  The original
: "readonly" keyword later evolved into the "const" keyword, but
: unfortunately this is not the same thing.

Maybe a better keyword would be 'visible'. I don't see any technical
problem with implementing such a keyword.

It is probably time for a major overhaul in C keyword use. When looking
at the many uses that some keywords have, one thinks it's time to improve.
Ex: 'static'.. Can anybody count how many uses 'static' has? And how
different their meanings are?

Hi,
 Fellow C++ programmers:  How many times have you had to provide trivial
functions so that clients could look into private data?  How many lines of
code have you written to show the length of strings or number of items in a
linked list??  IMHO, it gets to be *very* annoying and I propose a new
keyword to solve this problem:

 (sound of fanfare)  readonly

 This means that this piece of data can be written to as if it were a
private data, while it can be read as if public.....

What do you think??


--
Neel Vasant Kumar     |  #include <disclaimer,h>
neel-kumar@uiowa.edu  |  WWW: http://d-is07.icaen.uiowa.edu/~nvkumar

In article <2rh9mr$4a3@news.icaen.uiowa.edu> nvkumar@icaen.uiowa.edu (Neel Vasant Kumar) writes:

>    (sound of fanfare)  readonly

>    This means that this piece of data can be written to as if it were a
>   private data, while it can be read as if public.....

>   What do you think??

Not a bad idea, but not necessarily a good idea either.  The original
"readonly" keyword later evolved into the "const" keyword, but
unfortunately this is not the same thing.

The "readonly" keyword would be handy, indeed, and would possibly make for
cleaner design, but is it _necessary_?  Would its introduction really help
that much?

Think of it this way -- "readonly" and "const", to a neophyte, would seem
to imply the same thing just by the names themselves.  A large point of
confusion I'm sure as newbies try to instantiate "readonly" classes.

It would almost seem like a new access specifier would be appropriate,
something like a "readonly:" access specifier.  Unfortunately, it's too
much of an exception, since "readonly:" would apply only to member data as
opposed to member functions:

class foo
{
  readonly:
    int a, b;
    int bar(); // error!
};

To sum:  would be helpful to many, and would prevent the plethora of
"GetMember()" functions, but this is more of a syntactical nicety than a
necessity.  Are there any technical reasons why a "readonly" keyword can't
be implemented?

Brian







--
+-----------------------------------------------------------------+
| Brian Hook            | Specializing in real-time 3D graphics   |
| Box 90315             |-----------------------------------------|
| Gainesville, FL 32607 | Internet: bwh@cis.ufl.edu | Free Tibet! |
+-----------------------------------------------------------------+

bwh@beach.cis.ufl.edu (Brian Hook) writes:

>Not a bad idea, but not necessarily a good idea either.  The original
>"readonly" keyword later evolved into the "const" keyword, but
>unfortunately this is not the same thing.

>The "readonly" keyword would be handy, indeed, and would possibly make for
>cleaner design, but is it _necessary_?  Would its introduction really help
>that much?

>It would almost seem like a new access specifier would be appropriate,
>something like a "readonly:" access specifier.  Unfortunately, it's too
>much of an exception, since "readonly:" would apply only to member data as
>opposed to member functions:

>class foo
>{
>  readonly:
>    int a, b;
>    int bar(); // error!
>};
No, readonly could very well apply to functions as well, like const does.
While the declaration of scalar return types would not make any difference,
returning a reference would make a difference: it could be used in
lvalue contexts only where appropriate. On the other hand, the violation
would more be like a constness violation than like an access violation.

>To sum:  would be helpful to many, and would prevent the plethora of
>"GetMember()" functions, but this is more of a syntactical nicety than a
>necessity.  Are there any technical reasons why a "readonly" keyword can't
>be implemented?
Implementation would be sort of like introducing a const modifier
depending on the inheritance context.

Whether this is worth doing, is another question.

--
 David Kastrup        dak@pool.informatik.rwth-aachen.de
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

In article <2rh9mr$4a3@news.icaen.uiowa.edu>, nvkumar@icaen.uiowa.edu (Neel Vasant Kumar) writes:
|> Hi,
|>  Fellow C++ programmers:  How many times have you had to provide trivial
|> functions so that clients could look into private data?
K = many times
|>  How many lines of
|> code have you written to show the length of strings or number of items in a
|> linked list??
K
|>  IMHO, it gets to be *very* annoying
writing good code is not supposed to be an easy task.

The point is: the client isn't looking at the field s.length, he 's not supposed
to know if the class string has a field named "lenght" which contains the information
he need (it's just an implementation choice, you can call ::strlen instead), he just
want its lenght.

Consider the lenght of a list, you can:
  - put a field (let's call it lenght) in the data structure and update this
field for each call to insert extract etc... if you choose your solution, the
 client code will be :   int list_lenght = l.lenght;
 - make a loop to count the number of elements (it may be a stupid solution,
but that's not the point (and in some situations, it may be a valid solution))
now the cient code is : int list_lenght = l.lenght();

the problems:
   -if you switch betwen the tow solutions, the client code must be changed
   -it's not homogen

anyway:

|> and I propose a new
|> keyword to solve this problem:
|>
|>  (sound of fanfare)  readonly

class C {
public:
 C();
       const int &read_only_field;
private:
      int field_value;
  .....
};

C::C()
: read_only_field(this->field_value),.... {}

and
|>  This means that this piece of data can be written to as if it were a
|> private data, while it can be read as if public.....
|>
|> What do you think??
I never think on friday....

|> --
|> Neel Vasant Kumar     |  #include <disclaimer,h>
|> neel-kumar@uiowa.edu  |  WWW: http://d-is07.icaen.uiowa.edu/~nvkumar

--
------------------------------------------------------------------------------
Alain Miniussi                       |
(avec le "i" avant le "u")           |
e-mail: miniussi@labri.u-bordeaux.fr |  "Si la pomme ne tombe pas,
tel : 56 84 69 16                    |   secoues l'arbre."
LaBRI, Univ. BORDEAUX I              |
351, cours de la Liberation          |             I. Newton
FRANCE                               |
------------------------------------------------------------------------------

In article <BWH.94May20005013@beach.cis.ufl.edu> bwh@beach.cis.ufl.edu (Brian Hook) writes:

   To sum:  would be helpful to many, and would prevent the plethora of
   "GetMember()" functions, but this is more of a syntactical nicety than a
   necessity.  Are there any technical reasons why a "readonly" keyword can't
   be implemented?


This isnt a reason it can't be implemented, but it the "GetMember()" is an
inline function, then it should optimized to the same code as the "readonly"
key word.

                   Brian Kilgore    harris.bkilgore@ic1d.harris.com

In article <BKILGORE.94May20131405@suw3au.ic1d.harris.com> bkilgore@suw3au.ic1d.harris.com (Brian Kilgore) writes:

> This isnt a reason it can't be implemented, but it the "GetMember()" is an
> inline function, then it should optimized to the same code as the "readonly"
> key word.

I don't think that optimization is the important issue -- it's more of a
syntactic nicety than anything else.  Are there situations where a variable
should be readable and not writable?  And do these situations occur so
frequently that the language needs to be extended yet again?  I don't know,
but I'd like to.

Later,

Brian



--
+-----------------------------------------------------------------+
| Brian Hook            | Specializing in real-time 3D graphics   |
| Box 90315             |-----------------------------------------|
| Gainesville, FL 32607 | Internet: bwh@cis.ufl.edu | Free Tibet! |
+-----------------------------------------------------------------+