Topic: Proposed new Class Access Modifier "restricted" to be
Author: lwb.ztexas@gmail.com
Date: Fri, 9 May 2014 11:03:33 -0700 (PDT)
Raw View
------=_Part_7_3874695.1399658613898
Content-Type: text/plain; charset=UTF-8
I Propose a new Class Access Modifier "*restricted*" to be used like
public, protected, private, etc.
Sometimes it would be nice to have a 4th Class Access Modifier, I'll call
it "*restricted*", which would be similar to "*private*", but which would
provide restricted access to members, methods, etc.,
*ONLY *within the *File *where the *Class *was defined (generally the *.h*file). The reasoning behind this would be to make the Compiler to provide
an additional restriction for access by *NOT *allowing
the member/method to be access in the corresponding *.cpp* file. This
would effectively *force *(or remind) the programmer to access the
(generally) member variable through defined methods and
*not allow access directly*.
It is not uncommon to have a member variable which you would prefer were
accessed *only *through some sort of function or method, hidden from the
overall class code. For example (in *.h* file):
class fooClass
{
...
protected:
inline void setFooVar(int val) { fooVar = val; }
inline int getFooVar(void) { return fooVar; }
private:
int fooVar;
}
In the above code, the methods *setFooVar *and *getFooVar *are used to
manipulate the private variable *fooVar*. The programmer desires that all
access to *fooVar *be
*restricted to these two functions onl*y. However, there is nothing to
prevent a subsequent programmer to accessing *fooVar *directly in a
corresponding *.cpp* file method, *e.g. fooVar = 10;* .
In my proposal, you would write the class code this way (*note the
restricted Access Modifier in the .h file*):
class fooClass
{
...
protected:
inline void setFooVar(int val) { fooVar = val; }
inline int getFooVar(void) { return fooVar; }
restricted:
int fooVar;
}
With this new *restricted *Access Modifier, the programmer can now insure
that any subsequent access of the *fooVar *member variable will *NOT *be
allowed within the code in the .*cpp *file,
therefore insuring that *all access* there (in the* .cpp* file) *MUST *be
achieved by using the methods *setFooVar *and *getFooVar*. Of course the
use of *restricted *would be optional,
*in thesame way which the use of const is generally optional, but forces a
more specific restriction on what types of data may be, for example, passed
as a parameter to a function*.
Currently, this sort of data hiding *can *be accomplished via the use of a
somewhat messy *parent class*, where the purpose of the *parent class* is *ONLY
*to hide data and force access
through specific member functions. For example:
class hideFooClass
{
...
protected:
inline void setFooVar(int val) { fooVar = val; }
inline int getFooVar(void) { return fooVar; }
private:
int fooVar;
}
class fooClass : public hideFooClass
{
// No access to *fooVar *here...
}
In the above example, I may use the methods *setFooVar *and *getFooVar* as
I please, but I *do not* have access to *fooVar*. The private member
variable *fooVar *is *hidden *from *fooClass*.
However, by using what I propose here, I believe would be much cleaner than
having to *obfuscate *the code with the addition of an additional class
meant *only to hide access* to *fooVar*.
In my opinion, the use of an additional Access Modifier *restricted*, would
be a much more elegant solution to this somewhat common problem.
I welcome any thoughts or ideas you may have relating to this...
Thank you,
*Lance Bledsoe*
*Austin, TexasMay 2014*
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7_3874695.1399658613898
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>I Propose a new Class Access Modifier "<b><i>restricte=
d</i></b>" to be used like public, protected, private, etc.<br><br>Sometime=
s it would be nice to have a 4th Class Access Modifier, I'll call it "<b>re=
stricted</b>", which would be similar to "<b>private</b>", but which =
would provide restricted access to members, methods, etc., <br><b>ONLY </b>=
within the <b>File </b>where the <b>Class </b>was defined (generally the <b=
>.h</b> file). The reasoning behind this would be to make the Compile=
r to provide an additional restriction for access by <b>NOT </b>allowing<br=
>the member/method to be access in the corresponding <b>.cpp</b> file. =
; This would effectively <b>force </b>(or remind) the programmer to access =
the (generally) member variable through defined methods and<br><b>not allow=
access directly</b>.<br><br>It is not uncommon to have a member variable w=
hich you would prefer were accessed <b>only </b>through some sort of functi=
on or method, hidden from the overall class code. For example (in <b>=
..h</b> file):<br><br><div style=3D"margin-left: 40px;">class fooClass<br>{<=
br> ...<br><br> protected:<br><br> =
; inline void setFooVar(int val) { fooV=
ar =3D val; }<br> inline int getF=
ooVar(void) { return fooVar; }<br><br> private:<br><br>&n=
bsp; int fooVar;<br>}<br></div><br>In t=
he above code, the methods <b>setFooVar </b>and <b>getFooVar </b>are used t=
o manipulate the private variable <b>fooVar</b>. The programmer desir=
es that all access to <b>fooVar </b>be <b>restricted to <br>these two funct=
ions onl</b>y. However, there is nothing to prevent a subsequent prog=
rammer to accessing <b>fooVar </b>directly in a corresponding <b>.cpp</b> f=
ile method, <b><i>e.g. fooVar =3D 10;</i></b> .<br><br>In my proposal, you =
would write the class code this way (<i>note the <b>restricted </b>Access M=
odifier in the<b> .h</b> file</i>):<br><br><div style=3D"margin-left: 40px;=
">class fooClass<br>{<br> ...<br><br> p=
rotected:<br><br> inline void set=
FooVar(int val) { fooVar =3D val; }<br> =
inline int getFooVar(void) { return fooVar; }<br><br> &nb=
sp; restricted:<br><br> int fooVa=
r;<br>}<br><br></div>With this new <b>restricted </b>Access Modifier, the p=
rogrammer can now insure that any subsequent access of the <b>fooVar </b>me=
mber variable will <b>NOT </b>be allowed within the code in the .<b>cpp </b=
>file,<br>therefore insuring that <b>all access</b> there (in the<b> .cpp</=
b> file) <b>MUST </b>be achieved by using the methods <b>setFooVar </b>and=
<b>getFooVar</b>. Of course the use of <i><b>restricted </b></i>woul=
d be optional, <i>in the<br>same way which the use of <b>const </b>is gener=
ally optional, but forces a more specific restriction on what types of data=
may be, for example, passed as a parameter to a function</i>.<br><br>Curre=
ntly, this sort of data hiding <u><b>can </b></u>be accomplished via the us=
e of a somewhat messy <i><b>parent class</b></i>, where the purpose of the =
<i><b>parent class</b></i> is <b>ONLY </b>to hide data and force access<br>=
through specific member functions. For example:<br><br><div style=3D"=
margin-left: 40px;">class hideFooClass<br>{<br> ...<br><b=
r> protected:<br><br> =
inline void setFooVar(int val) { fooVar =3D val; }<br> &n=
bsp; inline int getFooVar(void) { return fooVar; }<=
br><br> private:<br><br> &nb=
sp; int fooVar;<br>}<br></div><br><div style=3D"margin-left: 40px;">c=
lass fooClass : public hideFooClass<br>{<br> // No access=
to <b>fooVar </b>here...<br>}<br><br></div>In the above example, I may use=
the methods <b>setFooVar </b>and <b>getFooVar</b> as I please, but I <u><=
b>do not</b></u> have access to <b>fooVar</b>. The private member variable =
<b>fooVar </b>is <i><b>hidden </b></i>from <b>fooClass</b>.<br>However, by =
using what I propose here, I believe would be much cleaner than having to <=
i>obfuscate </i>the code with the addition of an additional class meant <i>=
<b>only to hide access</b></i> to <b>fooVar</b>. <br>In my opinion, t=
he use of an additional Access Modifier <i><b>restricted</b></i>, would be =
a much more elegant solution to this somewhat common problem.<br><br>I welc=
ome any thoughts or ideas you may have relating to this...<br><br>Thank you=
,<br><br><b>Lance Bledsoe</b><br><i>Austin, Texas<br>May 2014</i><br><br><b=
r><br><br><br><br><br><script charset=3D"UTF-8" src=3D"chrome://hdv/content=
/hdv.js" type=3D"application/javascript"></script><script charset=3D"UTF-8"=
src=3D"chrome://hdv/content/hdv.js" type=3D"application/javascript"></scri=
pt></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7_3874695.1399658613898--
.