Topic: Add simple syntax for accessing class member variables.
Author: drax325 <draxlerm@gmail.com>
Date: Thu, 12 Mar 2015 16:05:23 -0700 (PDT)
Raw View
------=_Part_102_541501943.1426201523333
Content-Type: multipart/alternative;
boundary="----=_Part_103_2134943662.1426201523333"
------=_Part_103_2134943662.1426201523333
Content-Type: text/plain; charset=UTF-8
Suppose you have variables you want public access, but don't want it to be
changed outside the class? You have a few options one is to make it
constant, but then it is also constant for the class. Or you make the
variable private and have a public function to allow access.
What if there was syntax that was as simple as the public/protected/private.
The addition would be to add for example read: write: and some combo rw:
which would be the default which is how it is now.
class foo{
public:
read:
int var;
};
read would have same scope syntax rules as public and applies to proceeding
variables.
e.g.
if you have
foo f;
f.var = 5; // * error var is read only
int x = f.var; // fine
Doing this would simplify the need to write several accessor functions, and
it would make the behavior will be necessarily inline.
I think it would be a powerful yet simple addition, and would detract from
other features.
--
---
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_103_2134943662.1426201523333
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Suppose you have variables you want public access, but don=
't want it to be changed outside the class? You have a few options one is t=
o make it constant, but then it is also constant for the class. Or you make=
the variable private and have a public function to allow access.<div><br><=
/div><div>What if there was syntax that was as simple as the public/protect=
ed/private.</div><div>The addition would be to add for example read: =
write: and some combo rw: which would be the default which is how it =
is now.</div><div><br></div><div>class foo{</div><div> =
public:</div><div> read:</div><div> =
int var;</div><div>};</div><div>read would have=
same scope syntax rules as public and applies to proceeding variables.</di=
v><div>e.g.</div><div>if you have </div><div>foo f;</div><div><br></di=
v><div>f.var =3D 5; // * error var is read only</div><div>int x =3D f.var; =
// fine</div><div><br></div><div>Doing this would simplify the =
need to write several accessor functions, and it would make the behavior wi=
ll be necessarily inline. </div><div>I think it would be a powerful ye=
t simple addition, and would detract from other features.</div></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_103_2134943662.1426201523333--
------=_Part_102_541501943.1426201523333--
.
Author: Cleiton Santoia <cleitonsantoia@gmail.com>
Date: Thu, 12 Mar 2015 16:25:42 -0700 (PDT)
Raw View
------=_Part_70_3406989.1426202743012
Content-Type: multipart/alternative;
boundary="----=_Part_71_1426689301.1426202743013"
------=_Part_71_1426689301.1426202743013
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
const ?
Em quinta-feira, 12 de mar=C3=A7o de 2015 20:05:23 UTC-3, drax325 escreveu:
>
> Suppose you have variables you want public access, but don't want it to b=
e=20
> changed outside the class? You have a few options one is to make it=20
> constant, but then it is also constant for the class. Or you make the=20
> variable private and have a public function to allow access.
>
> What if there was syntax that was as simple as the=20
> public/protected/private.
> The addition would be to add for example read: write: and some combo rw=
:=20
> which would be the default which is how it is now.
>
> class foo{
> public:
> read:
> int var;
> };
> read would have same scope syntax rules as public and applies to=20
> proceeding variables.
> e.g.
> if you have=20
> foo f;
>
> f.var =3D 5; // * error var is read only
> int x =3D f.var; // fine
>
> Doing this would simplify the need to write several accessor functions,=
=20
> and it would make the behavior will be necessarily inline.=20
> I think it would be a powerful yet simple addition, and would detract fro=
m=20
> other features.
>
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_71_1426689301.1426202743013
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
const ?<br><br>Em quinta-feira, 12 de mar=C3=A7o de 2015 20:05:23 UTC-3, dr=
ax325 escreveu:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">Suppose you have variables you want public access, but don't want it to =
be changed outside the class? You have a few options one is to make it cons=
tant, but then it is also constant for the class. Or you make the variable =
private and have a public function to allow access.<div><br></div><div>What=
if there was syntax that was as simple as the public/protected/private.</d=
iv><div>The addition would be to add for example read: write: and som=
e combo rw: which would be the default which is how it is now.</div><=
div><br></div><div>class foo{</div><div> public:</div><=
div> read:</div><div> =
int var;</div><div>};</div><div>read would have same scope sy=
ntax rules as public and applies to proceeding variables.</div><div>e.g.</d=
iv><div>if you have </div><div>foo f;</div><div><br></div><div>f.var =
=3D 5; // * error var is read only</div><div>int x =3D f.var; // &nbs=
p;fine</div><div><br></div><div>Doing this would simplify the need to write=
several accessor functions, and it would make the behavior will be necessa=
rily inline. </div><div>I think it would be a powerful yet simple addi=
tion, and would detract from other features.</div></div></blockquote>
<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_71_1426689301.1426202743013--
------=_Part_70_3406989.1426202743012--
.
Author: drax325 <draxlerm@gmail.com>
Date: Thu, 12 Mar 2015 16:33:54 -0700 (PDT)
Raw View
------=_Part_119_112739922.1426203234660
Content-Type: multipart/alternative;
boundary="----=_Part_120_739292400.1426203234660"
------=_Part_120_739292400.1426203234660
Content-Type: text/plain; charset=UTF-8
const would not be equivalent. The goal is to, externally of the class, the
variable would be immutable like const, but we want to it to remain mutable
within the class scope.
On Thursday, March 12, 2015 at 6:25:43 PM UTC-5, Cleiton Santoia wrote:
>
> const ?
>
>
>
--
---
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_120_739292400.1426203234660
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">const would not be equivalent. The goal is to, externally =
of the class, the variable would be immutable like const, but we want to it=
to remain mutable within the class scope.<br><br>On Thursday, March 12, 20=
15 at 6:25:43 PM UTC-5, Cleiton Santoia wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">const ?<br><br><br></blockquote></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_120_739292400.1426203234660--
------=_Part_119_112739922.1426203234660--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Mar 2015 17:28:09 -0700 (PDT)
Raw View
------=_Part_82_1341235374.1426206489993
Content-Type: multipart/alternative;
boundary="----=_Part_83_1020768428.1426206489998"
------=_Part_83_1020768428.1426206489998
Content-Type: text/plain; charset=UTF-8
Except that accessors are better in almost every way.
Accessors create *proper* encapsulation, by isolating the outside world
from the implementation's details. With your way, if you want to change the
internal representation of some read-only variable, then everyone who uses
your class will be affected. If there was an accessor, you could provide
compatibility via the accessor's implementation. No outside code would be
affected by a change to private implementations.
--
---
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_83_1020768428.1426206489998
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Except that accessors are better in almost every way.<br><=
br>Accessors create <i>proper</i> encapsulation, by isolating the outside w=
orld from the implementation's details. With your way, if you want to chang=
e the internal representation of some read-only variable, then everyone who=
uses your class will be affected. If there was an accessor, you could prov=
ide compatibility via the accessor's implementation. No outside code would =
be affected by a change to private implementations.<br></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_83_1020768428.1426206489998--
------=_Part_82_1341235374.1426206489993--
.
Author: drax325 <draxlerm@gmail.com>
Date: Thu, 12 Mar 2015 18:25:24 -0700 (PDT)
Raw View
------=_Part_232_708075648.1426209924489
Content-Type: multipart/alternative;
boundary="----=_Part_233_1420527909.1426209924489"
------=_Part_233_1420527909.1426209924489
Content-Type: text/plain; charset=UTF-8
I find it hard to see how adding this to language would cause problems if
the class were changed.
>
> So say the contract with user is read only. If the class change is a type
> change , then the user would be affected equally for both ways. If you
> switch from public to private access the user would be affected in either
> case. If you wanted to return a transformed type, you could leave read only
> variable and add a function with transformed type, the user would not be
> affected. Removing read-only would also not affect user.
>
Could you give an example?
--
---
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_233_1420527909.1426209924489
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I find it hard to see how adding this to language would ca=
use problems if the class were changed.<div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><br>So say the contract with user is read on=
ly. If the class change is a type change , then the user would be aff=
ected equally for both ways. If you switch from public to private access th=
e user would be affected in either case. If you wanted to return a transfor=
med type, you could leave read only variable and add a function with transf=
ormed type, the user would not be affected. Removing read-only would also n=
ot affect user.</div></blockquote><div><br></div><div>Could you give an exa=
mple?</div><div> </div></div></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_233_1420527909.1426209924489--
------=_Part_232_708075648.1426209924489--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Mar 2015 19:56:07 -0700 (PDT)
Raw View
------=_Part_183_2061718756.1426215367499
Content-Type: multipart/alternative;
boundary="----=_Part_184_1658487747.1426215367500"
------=_Part_184_1658487747.1426215367500
Content-Type: text/plain; charset=UTF-8
On Thursday, March 12, 2015 at 9:25:24 PM UTC-4, drax325 wrote:
>
> I find it hard to see how adding this to language would cause problems if
> the class were changed.
>
>>
>> So say the contract with user is read only. If the class change is a
>> type change , then the user would be affected equally for both ways. If you
>> switch from public to private access the user would be affected in either
>> case. If you wanted to return a transformed type, you could leave read only
>> variable and add a function with transformed type, the user would not be
>> affected. Removing read-only would also not affect user.
>>
>
> Could you give an example?
>
>
OK. Let's say you have a class. And it has a name, which you want to be
publicly accessible, but read-only when accessed in that way.
class ReadOnly
{
public:
read:
std::string name;
};
Now, time passes. You need to change the internals to store the name in a
Unicode string:
class ReadOnly
{
public:
read:
UnicodeString name;
};
Even if UnicodeString had a completely identical interface to std::string
(and it would be a horrible UnicodeString if it did), you've still broken
every user of your 'name' field. They all must update to use your
UnicodeString type. Oh sure, liberal use of 'auto' can minimize that to a
degree. But it won't stop people who do "obj.name.c_str();" from failing.
Here's the accessor case.
class Accessor
{
private:
std::string name;
public:
const std::string &GetName() const {return name;}
};
Now, if you change the internals:
class Accessor
{
private:
UnicodeString name;
public:
std::string GetName() const {return name.Convert(utf8_encoding);}
const UnicodeString &GetUnicodeName() {return name;}
};
See the difference? The change of the return type of GetName() from a
const& to a value breaks no code. Yes, it forces the function to do a
potentially expensive conversion/copy. But at least all the code compiles
and functions. So each user can upgrade to the UnicodeString when they want
to.
Oh sure, maybe you want to break everyone, to force them to upgrade. But
you can do that with accessors too; just change the return type. With
accessors, you have a choice, made on a case-by-case basis. Your method
doesn't give you the choice; you're going to break everyone.
--
---
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_184_1658487747.1426215367500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 12, 2015 at 9:25:24 PM UTC-4, drax325 w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I find i=
t hard to see how adding this to language would cause problems if the class=
were changed.<div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><br>So say the contract with user is read only. If the class change =
is a type change , then the user would be affected equally for both ways. I=
f you switch from public to private access the user would be affected in ei=
ther case. If you wanted to return a transformed type, you could leave read=
only variable and add a function with transformed type, the user would not=
be affected. Removing read-only would also not affect user.</div></blockqu=
ote><div><br></div><div>Could you give an example?</div><div> </div></=
div></div></blockquote><div><br>OK. Let's say you have a class. And it has =
a name, which you want to be publicly accessible, but read-only when access=
ed in that way.<br><br>class ReadOnly<br>{<br> public:<br> read=
:<br> std::string name;<br>};<br><br>Now, time passes. Yo=
u need to change the internals to store the name in a Unicode string:<br><b=
r>class ReadOnly<br>{<br> public:<br> read:<br> &nbs=
p; UnicodeString name;<br>};<br><br>Even if UnicodeString had a completely =
identical interface to std::string (and it would be a horrible UnicodeStrin=
g if it did), you've still broken every user of your 'name' field. They all=
must update to use your UnicodeString type. Oh sure, liberal use of 'auto'=
can minimize that to a degree. But it won't stop people who do "obj.name.c=
_str();" from failing.<br><br>Here's the accessor case.<br><br>class Access=
or<br>{<br>private:<br> std::string name;<br>public:<br> const =
std::string &GetName() const {return name;}<br>};<br><br>Now, if you ch=
ange the internals:<br><br>class Accessor<br>{<br>private:<br> Unicod=
eString name;<br>public:<br> std::string GetName() const {return name=
..Convert(utf8_encoding);}<br> const UnicodeString &GetUnicodeName=
() {return name;}<br>};<br><br>See the difference? The change of the return=
type of GetName() from a const& to a value breaks no code. Yes, it for=
ces the function to do a potentially expensive conversion/copy. But at leas=
t all the code compiles and functions. So each user can upgrade to the Unic=
odeString when they want to.<br><br>Oh sure, maybe you want to break everyo=
ne, to force them to upgrade. But you can do that with accessors too; just =
change the return type. With accessors, you have a choice, made on a case-b=
y-case basis. Your method doesn't give you the choice; you're going to brea=
k everyone. <br></div></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_184_1658487747.1426215367500--
------=_Part_183_2061718756.1426215367499--
.
Author: drax325 <draxlerm@gmail.com>
Date: Thu, 12 Mar 2015 20:48:27 -0700 (PDT)
Raw View
------=_Part_25_1981790846.1426218507512
Content-Type: multipart/alternative;
boundary="----=_Part_26_487383752.1426218507512"
------=_Part_26_487383752.1426218507512
Content-Type: text/plain; charset=UTF-8
Yes if you use the new class with old code it would still compile with
encapsulation, but you had to create a compatibility function. This use of
encapsulation is really like hiding things under the carpet, you are just
hiding compile errors even though the data changed typed. If the class is
using Unicode and converts to ascii that is data loss. Who knows what that
would causes; lose half of the text? Depending on what the class is
responsible for. Or worse the class store extra data and old functions to
maintain compatabilites, which case you should have two versions of that
class.
If you were to use the new class. I would think you might want to upgrade
the system anyways and detecting type mismatch is easy to refactor, than if
you had functions overloaded so it would go unnoticed.
So, I still don't get your position that encapsulation would protect from
changes. If you remove the compatability function. Both examples a change
in type changes access so they are equivalent in that regard. Also adding
this would remove that ability.
--
---
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_26_487383752.1426218507512
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes if you use the new class with old code it would still =
compile with encapsulation, but you had to create a compatibility function.=
This use of encapsulation is really like hiding things under the carpet, y=
ou are just hiding compile errors even though the data changed typed. If th=
e class is using Unicode and converts to ascii that is data loss. Who knows=
what that would causes; lose half of the text? Depending on what the class=
is responsible for. Or worse the class store extra data and old functions =
to maintain compatabilites, which case you should have two versions of that=
class. <div><br></div><div>If you were to use the new class. I would =
think you might want to upgrade the system anyways and detecting type misma=
tch is easy to refactor, than if you had functions overloaded so it would g=
o unnoticed. </div><div><br></div><div>So, I still don't get your posi=
tion that encapsulation would protect from changes. If you remove the compa=
tability function. Both examples a change in type changes access so they ar=
e equivalent in that regard. Also adding this would remove that ability.<br=
></div></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_26_487383752.1426218507512--
------=_Part_25_1981790846.1426218507512--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Mar 2015 22:27:09 -0700 (PDT)
Raw View
------=_Part_290_1307865255.1426224430126
Content-Type: multipart/alternative;
boundary="----=_Part_291_1796213740.1426224430126"
------=_Part_291_1796213740.1426224430126
Content-Type: text/plain; charset=UTF-8
On Thursday, March 12, 2015 at 11:48:27 PM UTC-4, drax325 wrote:
>
> Yes if you use the new class with old code it would still compile with
> encapsulation, but you had to create a compatibility function. This use of
> encapsulation is really like hiding things under the carpet, you are just
> hiding compile errors even though the data changed typed. If the class is
> using Unicode and converts to ascii that is data loss. Who knows what that
> would causes; lose half of the text? Depending on what the class is
> responsible for. Or worse the class store extra data and old functions to
> maintain compatabilites, which case you should have two versions of that
> class.
>
Now you're debating the *particulars* of the example, rather than the
essential nature of the example itself. It could have been a change where
you store the first and last names in separate variables, a fact that no
external user needs to be aware of. The "compatabilities[sic]" function
would simply return a concatenation of the two members, with a space in the
middle.
The point is that, with accessors, if it is at all possible to change
internals without changing the interface, you can. With your method, you
cannot.
Your privates are exposed, and some things cannot be unseen.
> If you were to use the new class. I would think you might want to upgrade
> the system anyways and detecting type mismatch is easy to refactor, than if
> you had functions overloaded so it would go unnoticed.
>
A point that I noted at the end of my post: "Oh sure, maybe you want to
break everyone, to force them to upgrade. But you can do that with
accessors too; just change the return type." Please read the whole thing
before you respond.
> So, I still don't get your position that encapsulation would protect from
> changes. If you remove the compatability function. Both examples a change
> in type changes access so they are equivalent in that regard. Also adding
> this would remove that ability.
>
.... Listen to what you're saying for a moment.
You are saying that encapsulation doesn't protect you from changes, if you *remove
the part of encapsulation that protects you from changes*
<https://en.wikipedia.org/wiki/Information_hiding#Encapsulation> (ie: "the
compatability[sic] function").
If you assume your own conclusion, you can prove *anything*.
--
---
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_291_1796213740.1426224430126
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 12, 2015 at 11:48:27 PM UTC-4, drax325 =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Yes if =
you use the new class with old code it would still compile with encapsulati=
on, but you had to create a compatibility function. This use of encapsulati=
on is really like hiding things under the carpet, you are just hiding compi=
le errors even though the data changed typed. If the class is using Unicode=
and converts to ascii that is data loss. Who knows what that would causes;=
lose half of the text? Depending on what the class is responsible for. Or =
worse the class store extra data and old functions to maintain compatabilit=
es, which case you should have two versions of that class. </div></blo=
ckquote><div><br>Now you're debating the <i>particulars</i> of the example,=
rather than the essential nature of the example itself. It could have been=
a change where you store the first and last names in separate variables, a=
fact that no external user needs to be aware of. The "compatabilities[sic]=
" function would simply return a concatenation of the two members, with a s=
pace in the middle.<br><br>The point is that, with accessors, if it is at a=
ll possible to change internals without changing the interface, you can. Wi=
th your method, you cannot.<br><br>Your privates are exposed, and some thin=
gs cannot be unseen.<br> </div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div></div><div>If you were to use the new class. I =
would think you might want to upgrade the system anyways and detecting type=
mismatch is easy to refactor, than if you had functions overloaded so it w=
ould go unnoticed.</div></div></blockquote><div><br>A point that I noted at=
the end of my post: "Oh sure, maybe you want to break everyone, to force t=
hem to upgrade. But
you can do that with accessors too; just change the return type." Please r=
ead the whole thing before you respond.<br> </div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>So, I still don't=
get your position that encapsulation would protect from changes. If you re=
move the compatability function. Both examples a change in type changes acc=
ess so they are equivalent in that regard. Also adding this would remove th=
at ability.<br></div></div></blockquote><div><br>... Listen to what you're =
saying for a moment.<br><br>You are saying that encapsulation doesn't prote=
ct you from changes, if you <a href=3D"https://en.wikipedia.org/wiki/Inform=
ation_hiding#Encapsulation"><i>remove the part of encapsulation that protec=
ts you from changes</i></a> (ie: "the compatability[sic] function").<br><br=
>If you assume your own conclusion, you can prove <i>anything</i>.<br></div=
></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_291_1796213740.1426224430126--
------=_Part_290_1307865255.1426224430126--
.
Author: Alexander Nikolov <sasho648@mail.bg>
Date: Fri, 13 Mar 2015 03:45:04 -0700 (PDT)
Raw View
------=_Part_514_456685727.1426243504581
Content-Type: multipart/alternative;
boundary="----=_Part_515_410459311.1426243504581"
------=_Part_515_410459311.1426243504581
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This was already discussed I believe - check this=20
<https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/get$=
2Fsetters/std-proposals/1UVAhc6NbGc/qJOOJIXN8l8J>
..
I believe the best solution for this problem is enabling private and=20
protected members inside anonymous union when they're declared as member of=
=20
structures. Eg.:
class foo {
union
{
const int var; //access 'var' from outside the class=20
private:
int _var; //access 'var' from inside the class=20
} ;
} ;
=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 13 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 1=
:05:23 UTC+2, drax325 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> Suppose you have variables you want public access, but don't want it to b=
e=20
> changed outside the class? You have a few options one is to make it=20
> constant, but then it is also constant for the class. Or you make the=20
> variable private and have a public function to allow access.
>
> What if there was syntax that was as simple as the=20
> public/protected/private.
> The addition would be to add for example read: write: and some combo rw=
:=20
> which would be the default which is how it is now.
>
> class foo{
> public:
> read:
> int var;
> };
> read would have same scope syntax rules as public and applies to=20
> proceeding variables.
> e.g.
> if you have=20
> foo f;
>
> f.var =3D 5; // * error var is read only
> int x =3D f.var; // fine
>
> Doing this would simplify the need to write several accessor functions,=
=20
> and it would make the behavior will be necessarily inline.=20
> I think it would be a powerful yet simple addition, and would detract fro=
m=20
> other features.
>
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_515_410459311.1426243504581
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This was already discussed I believe - check <a href=3D"ht=
tps://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/get$2Fs=
etters/std-proposals/1UVAhc6NbGc/qJOOJIXN8l8J">this</a>.<div><br></div><div=
>I believe the best solution for this problem is enabling private and prote=
cted members inside anonymous union when they're declared as member of stru=
ctures. Eg.:<br><br></div><div class=3D"prettyprint" style=3D"border: 1px s=
olid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, =
250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> foo </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">union</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">var</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(136=
, 0, 0);"><span style=3D"color: #800;" class=3D"styled-by-prettify">//acces=
s 'var' from outside the class </span></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">private</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> _var</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">//access 'var' from inside the class </sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span></div></code></div><div><br><br><br>=D0=BF=
=D0=B5=D1=82=D1=8A=D0=BA, 13 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 1:05:23=
UTC+2, drax325 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr">Suppose you have variables you want=
public access, but don't want it to be changed outside the class? You have=
a few options one is to make it constant, but then it is also constant for=
the class. Or you make the variable private and have a public function to =
allow access.<div><br></div><div>What if there was syntax that was as simpl=
e as the public/protected/private.</div><div>The addition would be to add &=
nbsp;for example read: write: and some combo rw: which would be the d=
efault which is how it is now.</div><div><br></div><div>class foo{</div><di=
v> public:</div><div> read:</div><d=
iv> int var;</div><div>};</d=
iv><div>read would have same scope syntax rules as public and applies to pr=
oceeding variables.</div><div>e.g.</div><div>if you have </div><div>fo=
o f;</div><div><br></div><div>f.var =3D 5; // * error var is read only</div=
><div>int x =3D f.var; // fine</div><div><br></div><div>Doing t=
his would simplify the need to write several accessor functions, and it wou=
ld make the behavior will be necessarily inline. </div><div>I think it=
would be a powerful yet simple addition, and would detract from other feat=
ures.</div></div></blockquote></div></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_515_410459311.1426243504581--
------=_Part_514_456685727.1426243504581--
.
Author: Alexander Nikolov <sasho648@mail.bg>
Date: Fri, 13 Mar 2015 03:52:27 -0700 (PDT)
Raw View
------=_Part_143_2041220948.1426243947812
Content-Type: multipart/alternative;
boundary="----=_Part_144_749212211.1426243947812"
------=_Part_144_749212211.1426243947812
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This was already discussed I believe - check this=20
<https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/get$=
2Fsetters/std-proposals/1UVAhc6NbGc/qJOOJIXN8l8J>
..
I believe the best solution for this problem is enabling private and=20
protected members inside anonymous union when they're declared as member of=
=20
structures and the possibility to change their visibility inside it. Eg.:
class foo {
union
{
public:
const int var; //access 'var' from outside the class=20
private:
int _var; //access 'var' from inside the class=20
} ;
} ;
=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 13 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 1=
:05:23 UTC+2, drax325 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> Suppose you have variables you want public access, but don't want it to b=
e=20
> changed outside the class? You have a few options one is to make it=20
> constant, but then it is also constant for the class. Or you make the=20
> variable private and have a public function to allow access.
>
> What if there was syntax that was as simple as the=20
> public/protected/private.
> The addition would be to add for example read: write: and some combo rw=
:=20
> which would be the default which is how it is now.
>
> class foo{
> public:
> read:
> int var;
> };
> read would have same scope syntax rules as public and applies to=20
> proceeding variables.
> e.g.
> if you have=20
> foo f;
>
> f.var =3D 5; // * error var is read only
> int x =3D f.var; // fine
>
> Doing this would simplify the need to write several accessor functions,=
=20
> and it would make the behavior will be necessarily inline.=20
> I think it would be a powerful yet simple addition, and would detract fro=
m=20
> other features.
>
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_144_749212211.1426243947812
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This was already discussed I believe - check <a href=
=3D"https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/g=
et$2Fsetters/std-proposals/1UVAhc6NbGc/qJOOJIXN8l8J" target=3D"_blank" rel=
=3D"nofollow" style=3D"cursor: pointer;">this</a>.<div><br></div><div>I bel=
ieve the best solution for this problem is enabling private and protected m=
embers inside anonymous union when they're declared as member of structures=
and the possibility to change their visibility inside it. Eg.:</div><div><=
br><span style=3D"font-family: monospace; background-color: rgb(250, 250, 2=
50);"></span></div><div class=3D"prettyprint" style=3D"border: 1px solid rg=
b(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 25=
0);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> foo </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">union</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">public</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">var</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//access 'var' from outside the class </span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br> &=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">priv=
ate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>  =
; </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> _var</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">//access 'var' fr=
om inside the class </span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></code></div=
><div><span style=3D"font-family: monospace; background-color: rgb(250, 250=
, 250);"><br></span><br></div><div><br></div><br>=D0=BF=D0=B5=D1=82=D1=8A=
=D0=BA, 13 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 1:05:23 UTC+2, drax325 =
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr">Suppose you have variables you want public access, =
but don't want it to be changed outside the class? You have a few options o=
ne is to make it constant, but then it is also constant for the class. Or y=
ou make the variable private and have a public function to allow access.<di=
v><br></div><div>What if there was syntax that was as simple as the public/=
protected/private.</div><div>The addition would be to add for example=
read: write: and some combo rw: which would be the default which is =
how it is now.</div><div><br></div><div>class foo{</div><div> =
public:</div><div> read:</div><div> =
int var;</div><div>};</div><div>read wou=
ld have same scope syntax rules as public and applies to proceeding variabl=
es.</div><div>e.g.</div><div>if you have </div><div>foo f;</div><div><=
br></div><div>f.var =3D 5; // * error var is read only</div><div>int x =3D =
f.var; // fine</div><div><br></div><div>Doing this would simpli=
fy the need to write several accessor functions, and it would make the beha=
vior will be necessarily inline. </div><div>I think it would be a powe=
rful yet simple addition, and would detract from other features.</div></div=
></blockquote></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_144_749212211.1426243947812--
------=_Part_143_2041220948.1426243947812--
.
Author: drax325 <draxlerm@gmail.com>
Date: Fri, 13 Mar 2015 07:38:49 -0700 (PDT)
Raw View
------=_Part_473_1004766525.1426257529365
Content-Type: multipart/alternative;
boundary="----=_Part_474_1447069314.1426257529365"
------=_Part_474_1447069314.1426257529365
Content-Type: text/plain; charset=UTF-8
I'm saying that
class Read{
public:
read:
int x;
};
class Access{
private:
int x;
public:
int getX();
};
Are equivalent. The exception is that only getX() can be overloaded. But,
if you make a change you need to change both. You were making the
implication that lets say a general rule would be to always using function
encapsulation to protect changes. I've explained how that is a broken
mentality. It already goes against open/close principle, and really my
points explain it independently.
It's like having a car with 8 inch wheels, and few years later expecting to
put a bigger or small wheel (small might need different connection).
Yes you can have built in future proofing like interface/abstract class,
templates. But those don't require changes of the class, they would be know
when a person first uses the class, even though it would allow for future
changes.
If a person is making such drastic changes to a class it will always affect
the user. You simply wouldn't use the new classes for compatability, you
make sure you have old versions of library, or a library with both class
Foo; class newFoo;
Those changes are affect the user both ways. I don't see how you can't see
how compatibility overloading is not a significant change, or problem.
Especially since compatability in such a way will likely lead to bloated
classes, or arithmetic errors the user now suddenly has for trying to use a
new but externally equivalent class.
So for proof, encapsulation can protect from compile issue with changes,
but not from the bad problems explained.
Name an instance where a change from type A to type B, where A and B are
not equivalent, where you can use type A converted from B without having
arithmetic problems. Or size changes (the size change would make class
larger, and be problem for those who didn't use sizeof for managing storage
) though I will consider that separate problem like adding extra private
variables in class, would cause same problem.
That would be the only case where encapsulated accessor is ok. Otherwise
using the public read variable is just as good if anything does give
protection with type checking.
If you can't find an example then your protection is lost. For basic types
only half apply the case where B is smaller than A, but why would someone
want that?
And again the type checking would help notify the user of changes. While
such encapsulation would go unnoticed. And might become a weird bug.
So for those two reasons, direct access would be preferred.
On Friday, March 13, 2015 at 12:27:10 AM UTC-5, Nicol Bolas wrote:
>
>
> You are saying that encapsulation doesn't protect you from changes, if you *remove
> the part of encapsulation that protects you from changes*
> <https://en.wikipedia.org/wiki/Information_hiding#Encapsulation> (ie:
> "the compatability[sic] function").
>
> If you assume your own conclusion, you can prove *anything*.
>
--
---
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_474_1447069314.1426257529365
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm saying that <div>class Read{</div><div> &nb=
sp; public:</div><div> read:</div><div> &n=
bsp; int x;</div><div>};</div><div><br></div><div>class Access{</div=
><div> private: </div><div> &n=
bsp;int x;</div><div> public:</div><div> &=
nbsp; int getX();</div><div>};</div><div><br></div><div>Are equivalen=
t. The exception is that only getX() can be overloaded. But, if you make a =
change you need to change both. You were making the implication that lets s=
ay a general rule would be to always using function encapsulation to protec=
t changes. I've explained how that is a broken mentality. It already goes a=
gainst open/close principle, and really my points explain it independently.=
</div><div><br></div><div>It's like having a car with 8 inch wheels, and fe=
w years later expecting to put a bigger or small wheel (small might need di=
fferent connection). </div><div>Yes you can have built in future proof=
ing like interface/abstract class, templates. But those don't require chang=
es of the class, they would be know when a person first uses the class, eve=
n though it would allow for future changes.</div><div>If a person is making=
such drastic changes to a class it will always affect the user. You simply=
wouldn't use the new classes for compatability, you make sure you have old=
versions of library, or a library with both class Foo; class newFoo;=
</div><div>Those changes are affect the user both ways. I don't see h=
ow you can't see how compatibility overloading is not a significant change,=
or problem. Especially since compatability in such a way will likely lead =
to bloated classes, or arithmetic errors the user now suddenly has for tryi=
ng to use a new but externally equivalent class.</div><div><br></div><div>S=
o for proof, encapsulation can protect from compile issue with changes, but=
not from the bad problems explained. </div><div><br></div><div>Name a=
n instance where a change from type A to type B, where A and B are not equi=
valent, where you can use type A converted from B without having arithmetic=
problems. Or size changes (the size change would make class larger, and be=
problem for those who didn't use sizeof for managing storage ) thoug=
h I will consider that separate problem like adding extra private variables=
in class, would cause same problem. </div><div><br></div><div>That wo=
uld be the only case where encapsulated accessor is ok. Otherwise using the=
public read variable is just as good if anything does give protection with=
type checking.</div><div>If you can't find an example then your protection=
is lost. For basic types only half apply the case where B is smaller than =
A, but why would someone want that? </div><div><br></div><div>And agai=
n the type checking would help notify the user of changes. While such encap=
sulation would go unnoticed. And might become a weird bug.</div><div><br></=
div><div>So for those two reasons, direct access would be preferred. <=
/div><div><br>On Friday, March 13, 2015 at 12:27:10 AM UTC-5, Nicol Bolas w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br=
>You are saying that encapsulation doesn't protect you from changes, if you=
<a href=3D"https://en.wikipedia.org/wiki/Information_hiding#Encapsulation"=
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www=
..google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInformation_hid=
ing%23Encapsulation\46sa\75D\46sntz\0751\46usg\75AFQjCNFn3v7uEKcLfZfrTefOSW=
ByTti7HA';return true;" onclick=3D"this.href=3D'https://www.google.com/url?=
q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInformation_hiding%23Encapsulat=
ion\46sa\75D\46sntz\0751\46usg\75AFQjCNFn3v7uEKcLfZfrTefOSWByTti7HA';return=
true;"><i>remove the part of encapsulation that protects you from changes<=
/i></a> (ie: "the compatability[sic] function").<br><br>If you assume your =
own conclusion, you can prove <i>anything</i>.<br></div></div></blockquote>=
</div></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_474_1447069314.1426257529365--
------=_Part_473_1004766525.1426257529365--
.
Author: drax325 <draxlerm@gmail.com>
Date: Fri, 13 Mar 2015 07:44:56 -0700 (PDT)
Raw View
------=_Part_60_365445203.1426257896831
Content-Type: multipart/alternative;
boundary="----=_Part_61_234296401.1426257896831"
------=_Part_61_234296401.1426257896831
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
If such syntax worked, that would be equivalent functionally. My gcc is=20
complaining that a private member is in anonymous union.
Though a shorter syntax would be better like
public: read int x;
On Friday, March 13, 2015 at 5:52:27 AM UTC-5, Alexander Nikolov wrote:
>
> This was already discussed I believe - check this=20
> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/ge=
t$2Fsetters/std-proposals/1UVAhc6NbGc/qJOOJIXN8l8J>
> .
>
> I believe the best solution for this problem is enabling private and=20
> protected members inside anonymous union when they're declared as member =
of=20
> structures and the possibility to change their visibility inside it. Eg.:
>
> class foo {
>
> union
> {
> public:
> const int var; //access 'var' from outside the class=20
>
> private:
> int _var; //access 'var' from inside the class=20
> } ;
> } ;
>
>
>
>
> =D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 13 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3.,=
1:05:23 UTC+2, drax325 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>>
>> Suppose you have variables you want public access, but don't want it to=
=20
>> be changed outside the class? You have a few options one is to make it=
=20
>> constant, but then it is also constant for the class. Or you make the=20
>> variable private and have a public function to allow access.
>>
>> What if there was syntax that was as simple as the=20
>> public/protected/private.
>> The addition would be to add for example read: write: and some combo=20
>> rw: which would be the default which is how it is now.
>>
>> class foo{
>> public:
>> read:
>> int var;
>> };
>> read would have same scope syntax rules as public and applies to=20
>> proceeding variables.
>> e.g.
>> if you have=20
>> foo f;
>>
>> f.var =3D 5; // * error var is read only
>> int x =3D f.var; // fine
>>
>> Doing this would simplify the need to write several accessor functions,=
=20
>> and it would make the behavior will be necessarily inline.=20
>> I think it would be a powerful yet simple addition, and would detract=20
>> from other features.
>>
>
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_61_234296401.1426257896831
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If such syntax worked, that would be equivalent functional=
ly. My gcc is complaining that a private member is in anonymous union.<div>=
Though a shorter syntax would be better like</div><div> public:  =
; read int x;<br><br>On Friday, March 13, 2015 at 5:52:27 AM UTC-5, Alexand=
er Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">This was already discussed I believe - check <a href=3D"https://gr=
oups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/get$2Fsetters/s=
td-proposals/1UVAhc6NbGc/qJOOJIXN8l8J" rel=3D"nofollow" target=3D"_blank" o=
nmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!s=
earchin/std-proposals/get$2Fsetters/std-proposals/1UVAhc6NbGc/qJOOJIXN8l8J'=
;return true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.o=
rg/forum/#!searchin/std-proposals/get$2Fsetters/std-proposals/1UVAhc6NbGc/q=
JOOJIXN8l8J';return true;">this</a>.<div><br></div><div>I believe the best =
solution for this problem is enabling private and protected members inside =
anonymous union when they're declared as member of structures and the possi=
bility to change their visibility inside it. Eg.:</div><div><br><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250)"></span></div><=
div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgro=
und-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">class</sp=
an><span style=3D"color:#000"> foo </span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#000"><br><br> </span><span styl=
e=3D"color:#008">union</span><span style=3D"color:#000"><br> &=
nbsp; </span><span style=3D"color:#660">{</span><span style=3D"color:#000">=
<br> </span><span style=3D"color:#008">public</span><sp=
an style=3D"color:#660">:</span><span style=3D"color:#000"><br>  =
; </span><span style=3D"color:#008">const</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">int</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">var</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#800">//access 'var' from outside the class </span><span style=3D"colo=
r:#000"><br><br> </span><span style=3D"color:#008">priv=
ate</span><span style=3D"color:#660">:</span><span style=3D"color:#000"><br=
> </span><span style=3D"color:#008">int</=
span><span style=3D"color:#000"> _var</span><span style=3D"color:#660">;</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#800">//access =
'var' from inside the class </span><span style=3D"color:#000"><br> &n=
bsp; </span><span style=3D"color:#660">}</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
><br></span><span style=3D"color:#660">}</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">;</span></div></code></div><div><span sty=
le=3D"font-family:monospace;background-color:rgb(250,250,250)"><br></span><=
br></div><div><br></div><br>=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 13 =D0=BC=D0=B0=
=D1=80=D1=82 2015 =D0=B3., 1:05:23 UTC+2, drax325 =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Suppo=
se you have variables you want public access, but don't want it to be chang=
ed outside the class? You have a few options one is to make it constant, bu=
t then it is also constant for the class. Or you make the variable private =
and have a public function to allow access.<div><br></div><div>What if ther=
e was syntax that was as simple as the public/protected/private.</div><div>=
The addition would be to add for example read: write: and some combo =
rw: which would be the default which is how it is now.</div><div><br>=
</div><div>class foo{</div><div> public:</div><div>&nbs=
p; read:</div><div> =
int var;</div><div>};</div><div>read would have same scope syntax rul=
es as public and applies to proceeding variables.</div><div>e.g.</div><div>=
if you have </div><div>foo f;</div><div><br></div><div>f.var =3D 5; //=
* error var is read only</div><div>int x =3D f.var; // fine</d=
iv><div><br></div><div>Doing this would simplify the need to write several =
accessor functions, and it would make the behavior will be necessarily inli=
ne. </div><div>I think it would be a powerful yet simple addition, and=
would detract from other features.</div></div></blockquote></div></blockqu=
ote></div></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_61_234296401.1426257896831--
------=_Part_60_365445203.1426257896831--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Mar 2015 09:12:19 -0700 (PDT)
Raw View
------=_Part_928_900096170.1426263139846
Content-Type: multipart/alternative;
boundary="----=_Part_929_1041519722.1426263139846"
------=_Part_929_1041519722.1426263139846
Content-Type: text/plain; charset=UTF-8
On Friday, March 13, 2015 at 10:38:49 AM UTC-4, drax325 wrote:
>
> I'm saying that
> class Read{
> public:
> read:
> int x;
> };
>
> class Access{
> private:
> int x;
> public:
> int getX();
> };
>
> Are equivalent. The exception is that only getX() can be overloaded. But,
> if you make a change you need to change both.
>
But you don't need to change *outside code*. See the difference? If you
change the internal implementation in a properly encapsulated class, the
rest of the world doesn't need to know about it.
That's what encapsulation *means*: things inside the "capsule" are
insulated from things outside of it.
You were making the implication that lets say a general rule would be to
> always using function encapsulation to protect changes. I've explained how
> that is a broken mentality. It already goes against open/close principle,
> and really my points explain it independently.
>
That is arrant nonsense.
The open/close principle
<https://en.wikipedia.org/wiki/Open/closed_principle> is about how an
interface should change only through additions, not through breaking
changes. Proper encapsulation is what *allows* the open/close principle to
work. It's what allows you to change implementation details behind the
class without changing the interface. Thus, the interface remains *closed*
to changes, while the internals are *open* to adjustment as needed.
The open/close principle is not about never, ever making changes to a class
after you're written it. It's not about writing a class and then saying,
"the only way this class's code will ever change is if someone derives a
new class from it." It's about closing off the *interface* of the class
from changes, so that users of the class will not be broken if you change
it.
Private variables are not part of the interface of a class; they're
implementation details. And thus, they should be flexible and open to
change.
It's like having a car with 8 inch wheels, and few years later expecting to
> put a bigger or small wheel (small might need different connection).
>
And it might not. Why deny yourself the choice?
Yes you can have built in future proofing like interface/abstract class,
> templates. But those don't require changes of the class, they would be know
> when a person first uses the class, even though it would allow for future
> changes.
> If a person is making such drastic changes to a class it will always
> affect the user. You simply wouldn't use the new classes for compatability,
> you make sure you have old versions of library, or a library with both
> class Foo; class newFoo;
>
Those changes are affect the user both ways. I don't see how you can't see
> how compatibility overloading is not a significant change, or problem.
> Especially since compatability in such a way will likely lead to bloated
> classes, or arithmetic errors the user now suddenly has for trying to use a
> new but externally equivalent class.
>
What you call "compatibility overloading" is a *fundamental part* of
refactoring <https://en.wikipedia.org/wiki/Code_refactoring>. I have no
idea what software you've worked on, but on software I've been a part of,
this is an absolutely *vital* tool in being able to redesign the internals
of a system behind everyone's back.
Without proper encapsulation, refactoring is *impossible*.
> So for proof, encapsulation can protect from compile issue with changes,
> but not from the bad problems explained.
>
> Name an instance where a change from type A to type B, where A and B are
> not equivalent, where you can use type A converted from B without having
> arithmetic problems. Or size changes (the size change would make class
> larger, and be problem for those who didn't use sizeof for managing storage
> ) though I will consider that separate problem like adding extra private
> variables in class, would cause same problem.
>
That is a bizarre and completely absurd requirement.
If you "didn't use sizeof for managing storage" (I'll assume you're talking
about with malloc, which you generally ought not be using in C++ to begin
with), then your code is *already broken*. Why? Because C++ does not
mandate a specific size for objects based on their layout, across all
implementations. So unless you only ever compile your code for one specific
compiler, any such code is broken.
And what are "arithmetic problems"? If you're talking about pointer
arithmetic, then you're fine, since the language knows the size of all of
the objects automatically. If you're talking about "pointer arithmetic
where I cast it to a char*, add an arbitrary number to it, and cast it
back", then you're again *already broken*, because the standard doesn't let
you know a priori what the size of a class is. You only know if you ask it.
By all rights, your class's size is *not* part of its interface. Yes, it
affects user code, but user code handles this automatically. `new`, and all
equivalents thereof, know what your class's size is. And therefore, it will
work automatically if you change it. The only way this would be a problem
is if you are doing something fantastically stupid already.
And stupidity is not something people need to be protected from. That's a
basic rule of C++ design.
That would be the only case where encapsulated accessor is ok. Otherwise
> using the public read variable is just as good if anything does give
> protection with type checking.
> If you can't find an example then your protection is lost. For basic types
> only half apply the case where B is smaller than A, but why would someone
> want that?
>
> And again the type checking would help notify the user of changes.
>
And then your user switches to a product written by people who value *not
breaking their code*. Generally speaking, programmers don't like to have
their programs fail to compile when they update to a new version of a
library. *Especially* when it is due to internal changes that they could be
insulated from.
You know, with that whole encapsulation thing.
--
---
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_929_1041519722.1426263139846
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 13, 2015 at 10:38:49 AM UTC-4, drax325 wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I'm sayin=
g that <div>class Read{</div><div> public:</div><div>&nbs=
p; read:</div><div> int x;</div><d=
iv>};</div><div><br></div><div>class Access{</div><div> privat=
e: </div><div> int x;</div><div> =
; public:</div><div> int getX();</d=
iv><div>};</div><div><br></div><div>Are equivalent. The exception is that o=
nly getX() can be overloaded. But, if you make a change you need to change =
both.</div></div></blockquote><div><br>But you don't need to change <i>outs=
ide code</i>. See the difference? If you change the internal implementation=
in a properly encapsulated class, the rest of the world doesn't need to kn=
ow about it.<br><br>That's what encapsulation <i>means</i>: things inside t=
he "capsule" are insulated from things outside of it.<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>You were making =
the implication that lets say a general rule would be to always using funct=
ion encapsulation to protect changes. I've explained how that is a broken m=
entality. It already goes against open/close principle, and really my point=
s explain it independently.</div></div></blockquote><div><br>That is arrant=
nonsense.<br><br><a href=3D"https://en.wikipedia.org/wiki/Open/closed_prin=
ciple">The open/close principle</a> is about how an interface should change=
only through additions, not through breaking changes. Proper encapsulation=
is what <i>allows</i> the open/close principle to work. It's what allows y=
ou to change implementation details behind the class without changing the i=
nterface. Thus, the interface remains <i>closed</i> to changes, while the i=
nternals are <i>open</i> to adjustment as needed.<br><br>The open/close pri=
nciple is not about never, ever making changes to a class after you're writ=
ten it. It's not about writing a class and then saying, "the only way this =
class's code will ever change is if someone derives a new class from it." I=
t's about closing off the <i>interface</i> of the class from changes, so th=
at users of the class will not be broken if you change it.<br><br>Private v=
ariables are not part of the interface of a class; they're implementation d=
etails. And thus, they should be flexible and open to change.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It's lik=
e having a car with 8 inch wheels, and few years later expecting to put a b=
igger or small wheel (small might need different connection). </div></=
div></blockquote><div><br>And it might not. Why deny yourself the choice?<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>Yes you can have built in future proofing like interface/abstract class=
, templates. But those don't require changes of the class, they would be kn=
ow when a person first uses the class, even though it would allow for futur=
e changes.</div><div>If a person is making such drastic changes to a class =
it will always affect the user. You simply wouldn't use the new classes for=
compatability, you make sure you have old versions of library, or a librar=
y with both class Foo; class newFoo; <br></div></div></blockquote><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Those chang=
es are affect the user both ways. I don't see how you can't see how compati=
bility overloading is not a significant change, or problem. Especially sinc=
e compatability in such a way will likely lead to bloated classes, or arith=
metic errors the user now suddenly has for trying to use a new but external=
ly equivalent class.</div></div></blockquote><div><br>What you call "compat=
ibility overloading" is a <i>fundamental part</i> of <a href=3D"https://en.=
wikipedia.org/wiki/Code_refactoring">refactoring</a>. I have no idea what s=
oftware you've worked on, but on software I've been a part of, this is an a=
bsolutely <i>vital</i> tool in being able to redesign the internals of a sy=
stem behind everyone's back.<br><br>Without proper encapsulation, refactori=
ng is <i>impossible</i>.<br> </div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div></div><div>So for proof, encapsulation can =
protect from compile issue with changes, but not from the bad problems expl=
ained. </div><div><br></div><div>Name an instance where a change from =
type A to type B, where A and B are not equivalent, where you can use type =
A converted from B without having arithmetic problems. Or size changes (the=
size change would make class larger, and be problem for those who didn't u=
se sizeof for managing storage ) though I will consider that separate=
problem like adding extra private variables in class, would cause same pro=
blem.</div></div></blockquote><div><br>That is a bizarre and completely abs=
urd requirement.<br><br>If you "didn't use sizeof for managing storage" (I'=
ll assume you're talking about with malloc, which you generally ought not b=
e using in C++ to begin with), then your code is <i>already broken</i>. Why=
? Because C++ does not mandate a specific size for objects based on their l=
ayout, across all implementations. So unless you only ever compile your cod=
e for one specific compiler, any such code is broken.<br><br>And what are "=
arithmetic problems"? If you're talking about pointer arithmetic, then you'=
re fine, since the language knows the size of all of the objects automatica=
lly. If you're talking about "pointer arithmetic where I cast it to a char*=
, add an arbitrary number to it, and cast it back", then you're again <i>al=
ready broken</i>, because the standard doesn't let you know a priori what t=
he size of a class is. You only know if you ask it.<br><br>By all rights, y=
our class's size is <i>not</i> part of its interface. Yes, it affects user =
code, but user code handles this automatically. `new`, and all equivalents =
thereof, know what your class's size is. And therefore, it will work automa=
tically if you change it. The only way this would be a problem is if you ar=
e doing something fantastically stupid already.<br><br>And stupidity is not=
something people need to be protected from. That's a basic rule of C++ des=
ign.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div></div><div>That would be the only case where encapsulated accesso=
r is ok. Otherwise using the public read variable is just as good if anythi=
ng does give protection with type checking.</div><div>If you can't find an =
example then your protection is lost. For basic types only half apply the c=
ase where B is smaller than A, but why would someone want that? </div>=
<div><br></div><div>And again the type checking would help notify the user =
of changes.</div></div></blockquote><div><br>And then your user switches to=
a product written by people who value <i>not breaking their code</i>. Gene=
rally speaking, programmers don't like to have their programs fail to compi=
le when they update to a new version of a library. <i>Especially</i> when i=
t is due to internal changes that they could be insulated from.<br><br>You =
know, with that whole encapsulation thing.</div></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_929_1041519722.1426263139846--
------=_Part_928_900096170.1426263139846--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 13 Mar 2015 19:16:36 +0200
Raw View
On 13 March 2015 at 18:12, Nicol Bolas <jmckesson@gmail.com> wrote:
> By all rights, your class's size is not part of its interface. Yes, it
> affects user code, but user code handles this automatically. `new`, and all
I fail to see how "requires recompilation" is equal to "handles automatically".
Having said that, accessor functions or in-class-initialized references provide
a reasonable solution for many cases that this proposal covers. For the cases
those solutions don't cover, it seems to me that we should strive for expression
aliases, and allow such aliases to be class members. As the proposal stands,
its cost/benefit ratio is not convincing enough. Expression aliases are much
more general, therefore their cost/benefit ratio may end up being
better, although
their implementation cost is surely higher than the thing proposed in
this thread.
--
---
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/.
.
Author: drax325 <draxlerm@gmail.com>
Date: Fri, 13 Mar 2015 10:37:40 -0700 (PDT)
Raw View
------=_Part_689_48772184.1426268260560
Content-Type: multipart/alternative;
boundary="----=_Part_690_1522826981.1426268260560"
------=_Part_690_1522826981.1426268260560
Content-Type: text/plain; charset=UTF-8
>
>
> The open/close principle is not about never, ever making changes to a
> class after you're written it. It's not about writing a class and then
> saying, "the only way this class's code will ever change is if someone
> derives a new class from it." It's about closing off the *interface* of
> the class from changes, so that users of the class will not be broken if
> you change it.
>
It is about not changing it. And if you want changes derive from instead of
changing it. As changing internals will break it.
You really have no clue what I'm talking about . And now you are talking
about interfaces, I already mentioned that that handles things differently.
I'm talking about changes to concrete class, is going to affect the user.
Unless it simply is optimization changes inside of functions. But, adding /
changing variables or functions will affect the user.
I am saying that you are wrong that you can be insulated from internal
changes. Except with interfacing which doesn't change the original type but
can change the child used.
With interfacing. Say you have Class Animal if the internal changes
switches from Cat to Dog , you accessing the animal would not be a changed
type. So accessing animal directly or indirectly doesn't matter.
But, if the class used Dog and switched to Cat then you have problems. Who
would want some weird automatic conversion from Dog to Cat.
And if they added interface going from Dog to Animal you would have to
change how you use the class anyways.
By arithmetic problems. Say the class has an int32 x but switches to int64
x. In order to support compatability it would need to convert from int64
to int32. Or in your original example unicode to some ascii version. That
is data loss. Now suppose the user is insulated, by it being the one feed
the instance with int32 data and getting back int32, like a vector. But why
have a vector that stores int32 in int64 array?
But if the class is responsible for int64 it could easily produce something
that is out of range of int32. Maybe it is a counter. So then you use this
new class. It has the compatibility functions. You use int32 getCounter(),
and get a negative number. Then your code fails and you can't figure why,
until you realize someone secretly changed the class from int32 to int64.
And either case. This adds to the language, so you can still hold that
philosophy and do things that way, but everyone else can use a simple
syntax.
--
---
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_690_1522826981.1426268260560
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>The open/close principle is not about never, ever making chang=
es to a class after you're written it. It's not about writing a class and t=
hen saying, "the only way this class's code will ever change is if someone =
derives a new class from it." It's about closing off the <i>interface</i> o=
f the class from changes, so that users of the class will not be broken if =
you change it.<br></div></div></blockquote><div><br></div><div>It is about =
not changing it. And if you want changes derive from instead of changing it=
.. As changing internals will break it.</div><div><br></div><div><div>You re=
ally have no clue what I'm talking about . And now you are talking ab=
out interfaces, I already mentioned that that handles things differently. I=
'm talking about changes to concrete class, is going to affect the user. Un=
less it simply is optimization changes inside of functions. But, adding / c=
hanging variables or functions will affect the user. </div><div><br></=
div><div>I am saying that you are wrong that you can be insulated from inte=
rnal changes. Except with interfacing which doesn't change the original typ=
e but can change the child used.</div><div><br></div><div>With interfacing.=
Say you have Class Animal if the internal changes switches from Cat to Dog=
, you accessing the animal would not be a changed type. So accessing anima=
l directly or indirectly doesn't matter.</div><div>But, if the class used D=
og and switched to Cat then you have problems. Who would want some weird au=
tomatic conversion from Dog to Cat. </div><div>And if they added inter=
face going from Dog to Animal you would have to change how you use the clas=
s anyways. </div><div><br></div><div>By arithmetic problems. Say the c=
lass has an int32 x but switches to int64 x. In order to support comp=
atability it would need to convert from int64 to int32. Or in your original=
example unicode to some ascii version. That is data loss. Now suppose the =
user is insulated, by it being the one feed the instance with int32 data an=
d getting back int32, like a vector. But why have a vector that stores int3=
2 in int64 array?</div><div>But if the class is responsible for int64 it co=
uld easily produce something that is out of range of int32. Maybe it is a c=
ounter. So then you use this new class. It has the compatibility func=
tions. You use int32 getCounter(), and get a negative number. Then your cod=
e fails and you can't figure why, until you realize someone secretly change=
d the class from int32 to int64. </div></div><div><br></div><div><br><=
/div><div>And either case. This adds to the language, so you can still hold=
that philosophy and do things that way, but everyone else can use a simple=
syntax. </div><div><br></div><div><br></div></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_690_1522826981.1426268260560--
------=_Part_689_48772184.1426268260560--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Mar 2015 11:36:42 -0700 (PDT)
Raw View
------=_Part_5_1934327013.1426271802340
Content-Type: multipart/alternative;
boundary="----=_Part_6_1626659205.1426271802340"
------=_Part_6_1626659205.1426271802340
Content-Type: text/plain; charset=UTF-8
On Friday, March 13, 2015 at 1:37:40 PM UTC-4, drax325 wrote:
>
>
>> The open/close principle is not about never, ever making changes to a
>> class after you're written it. It's not about writing a class and then
>> saying, "the only way this class's code will ever change is if someone
>> derives a new class from it." It's about closing off the *interface* of
>> the class from changes, so that users of the class will not be broken if
>> you change it.
>>
>
> It is about not changing it. And if you want changes derive from instead
> of changing it. As changing internals will break it.
>
That is complete bunk. Here are several ways of having different
representations of data, while having the exact same interface. Changing
from one representation to the other will "break" noone's code.
class Foo
{
private:
std::string name;
public:
const std::string &GetName() const {return name;}
};
class Foo
{
private:
uint64_t dbHandle;
std::shared_ptr<Database> myDb;
public:
std::string GetName() const {return myDb->AccessField(dbHandle, "name");}
};
class Foo
{
private:
std::string firstname, lastname;
public:
std::string GetName() const {return firstname + " " + lastname;}
}
So there is no validity to your statement that "changing internals will
break it". At least, not by any reasonable definition of the word "break".
> You really have no clue what I'm talking about . And now you are talking
> about interfaces, I already mentioned that that handles things differently.
> I'm talking about changes to concrete class, is going to affect the user.
> Unless it simply is optimization changes inside of functions. But, adding /
> changing variables or functions will affect the user.
>
How do you define "affect"? By getting a library update at all, the user is
forced to recompile their application that uses it. That is the minimum
level of "affect" the user will have to do (assuming that dynamic linking
is not involved, but using C++ objects across dynamic libraries is already
something of a nightmare, and is outside of the bounds of the standard).
A well-designed library, with proper encapsulation and such, will require
nothing more than a recompile. To force anything more is a breaking change,
and by all good software development rules, breaking changes should be
avoided wherever *possible*.
Good encapsulation allows the implementer of an interface to make many
kinds of internal changes while avoiding breaking changes. Your proposal
doesn't make it possible to modify the nature of an exposed variable
without making breaking changes. It therefore represents bad encapsulation.
I am saying that you are wrong that you can be insulated from internal
> changes. Except with interfacing which doesn't change the original type but
> can change the child used.
>
> With interfacing. Say you have Class Animal if the internal changes
> switches from Cat to Dog , you accessing the animal would not be a changed
> type. So accessing animal directly or indirectly doesn't matter.
> But, if the class used Dog and switched to Cat then you have problems. Who
> would want some weird automatic conversion from Dog to Cat.
> And if they added interface going from Dog to Animal you would have to
> change how you use the class anyways.
>
You seem to be talking about class hierarchies. I have no idea how that
conversation got started, because nothing we've been discussing up until
now has dealt with them. Nor do I understand what that has to do with the
topic of discussion, which has nothing to do with inheritance.
By arithmetic problems. Say the class has an int32 x but switches to int64
> x. In order to support compatability it would need to convert from int64
> to int32. Or in your original example unicode to some ascii version. That
> is data loss. Now suppose the user is insulated, by it being the one feed
> the instance with int32 data and getting back int32, like a vector. But why
> have a vector that stores int32 in int64 array?
> But if the class is responsible for int64 it could easily produce
> something that is out of range of int32. Maybe it is a counter. So then you
> use this new class. It has the compatibility functions. You use int32
> getCounter(), and get a negative number. Then your code fails and you can't
> figure why, until you realize someone secretly changed the class from int32
> to int64.
>
If that is the case, then the change from an int32 to an int64 leaks
through the abstraction. In which case, you *have to* introduce a breaking
change.
See, I've never claimed that encapsulation makes it impossible for any
internal changes to affect outside users. But it means that, *where
appropriate*, the outside world can be isolated from internal changes. Your
way makes it impossible to create such isolation.
Furthermore, even in your case of integers, whether such isolation is
possible all depends on what the integer means. If it's some kind of
address hiding in an integer, then any reduction in its size is lossy, so
no compatibility is possible. However, if it represents something like a
file size, then reducing its size is usually not lossy. And one can easily
detect when such a reduction represents a loss of information and handle
that case appropriately.
Remember: the internal change here will not go *undocumented*. What your
docs will say is that you now support file sizes greater than 2GB. But you
leave the old interface there. All it needs to do is whatever your old code
would have done if it encountered a file size greater than 2GB.
The same goes for the UnicodeString case. Before, you didn't support
Unicode, so throwing Unicode strings at it would yield lossy behavior
*somewhere*. By supporting the old interface, you still have the lossy
behavior. But not everyone *cares* about Unicode support. Some people would
rather upgrade when they feel the need, rather than just because you added
support for something they don't use. And if you talk to your customers
about the change and they that still want the old API, or that they a
period of compatibility before making the change, you shouldn't break them.
See Python 2 vs 3 as a great example of this. Python 3 broke compatibility.
And what's the result? Fragmentation of the userbase. How many Python-based
projects abjectly refuse to support 3? Lots. I basically have no choice but
to learn Python 2, since few of the modules I want to use support 3.
And either case. This adds to the language, so you can still hold that
> philosophy and do things that way, but everyone else can use a simple
> syntax.
>
We shouldn't add features to the language that encourage bad design
decisions. Proper encapsulation allows the designer of the class to decide
if a change in the implementation must be a breaking change or not.
Improper encapsulation *removes* this choice; if you change the
implementation, even if it *could* have been compatible, it cannot be.
--
---
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_6_1626659205.1426271802340
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 13, 2015 at 1:37:40 PM UTC-4, drax325 wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>The open/close prin=
ciple is not about never, ever making changes to a class after you're writt=
en it. It's not about writing a class and then saying, "the only way this c=
lass's code will ever change is if someone derives a new class from it." It=
's about closing off the <i>interface</i> of the class from changes, so tha=
t users of the class will not be broken if you change it.<br></div></div></=
blockquote><div><br></div><div>It is about not changing it. And if you want=
changes derive from instead of changing it. As changing internals will bre=
ak it.</div></div></blockquote><div><br>That is complete bunk. Here are sev=
eral ways of having different representations of data, while having the exa=
ct same interface. Changing from one representation to the other will "brea=
k" noone's code.<br><br>class Foo<br>{<br>private:<br> std::string na=
me;<br><br>public:<br> const std::string &GetName() const {return=
name;}<br>};<br><br>class Foo<br>{<br>private:<br> uint64_t dbHandle=
;<br> std::shared_ptr<Database> myDb;<br><br>public:<br> =
std::string GetName() const {return myDb->AccessField(dbHandle, "name");=
}<br>};<br><br>class Foo<br>{<br>private:<br> std::string firstname, =
lastname;<br><br>public:<br> std::string GetName() const {return firs=
tname + " " + lastname;}<br>}<br><br>So there is no validity to your statem=
ent that "changing internals will break it". At least, not by any reasonabl=
e definition of the word "break".<br> </div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><div>You really have no clue what =
I'm talking about . And now you are talking about interfaces, I alrea=
dy mentioned that that handles things differently. I'm talking about change=
s to concrete class, is going to affect the user. Unless it simply is optim=
ization changes inside of functions. But, adding / changing variables or fu=
nctions will affect the user.</div></div></div></blockquote><div><br>How do=
you define "affect"? By getting a library update at all, the user is force=
d to recompile their application that uses it. That is the minimum level of=
"affect" the user will have to do (assuming that dynamic linking is not in=
volved, but using C++ objects across dynamic libraries is already something=
of a nightmare, and is outside of the bounds of the standard).<br><br>A we=
ll-designed library, with proper encapsulation and such, will require nothi=
ng more than a recompile. To force anything more is a breaking change, and =
by all good software development rules, breaking changes should be avoided =
wherever <i>possible</i>.<br><br>Good encapsulation allows the implementer =
of an interface to make many kinds of internal changes while avoiding break=
ing changes. Your proposal doesn't make it possible to modify the nature of=
an exposed variable without making breaking changes. It therefore represen=
ts bad encapsulation.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div></div><div>I am saying that you are wrong =
that you can be insulated from internal changes. Except with interfacing wh=
ich doesn't change the original type but can change the child used.</div><d=
iv><br></div><div>With interfacing. Say you have Class Animal if the intern=
al changes switches from Cat to Dog , you accessing the animal would not be=
a changed type. So accessing animal directly or indirectly doesn't matter.=
</div><div>But, if the class used Dog and switched to Cat then you have pro=
blems. Who would want some weird automatic conversion from Dog to Cat. =
;</div><div>And if they added interface going from Dog to Animal you would =
have to change how you use the class anyways.</div></div></div></blockquote=
><div><br>You seem to be talking about class hierarchies. I have no idea ho=
w that conversation got started, because nothing we've been discussing up u=
ntil now has dealt with them. Nor do I understand what that has to do with =
the topic of discussion, which has nothing to do with inheritance.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v></div><div>By arithmetic problems. Say the class has an int32 x but switc=
hes to int64 x. In order to support compatability it would need to co=
nvert from int64 to int32. Or in your original example unicode to some asci=
i version. That is data loss. Now suppose the user is insulated, by it bein=
g the one feed the instance with int32 data and getting back int32, like a =
vector. But why have a vector that stores int32 in int64 array?</div><div>B=
ut if the class is responsible for int64 it could easily produce something =
that is out of range of int32. Maybe it is a counter. So then you use this =
new class. It has the compatibility functions. You use int32 getCount=
er(), and get a negative number. Then your code fails and you can't figure =
why, until you realize someone secretly changed the class from int32 to int=
64.</div></div></div></blockquote><div><br>If that is the case, then the ch=
ange from an int32 to an int64 leaks through the abstraction. In which case=
, you <i>have to</i> introduce a breaking change.<br><br>See, I've never cl=
aimed that encapsulation makes it impossible for any internal changes to af=
fect outside users. But it means that, <i>where appropriate</i>, the outsid=
e world can be isolated from internal changes. Your way makes it impossible=
to create such isolation.<br><br>Furthermore, even in your case of integer=
s, whether such isolation is possible all depends on what the integer means=
.. If it's some kind of address hiding in an integer, then any reduction in =
its size is lossy, so no compatibility is possible. However, if it represen=
ts something like a file size, then reducing its size is usually not lossy.=
And one can easily detect when such a reduction represents a loss of infor=
mation and handle that case appropriately.<br><br>Remember: the internal ch=
ange here will not go <i>undocumented</i>. What your docs will say is that =
you now support file sizes greater than 2GB. But you leave the old interfac=
e there. All it needs to do is whatever your old code would have done if it=
encountered a file size greater than 2GB.<br><br>The same goes for the Uni=
codeString case. Before, you didn't support Unicode, so throwing Unicode st=
rings at it would yield lossy behavior <i>somewhere</i>. By supporting the =
old interface, you still have the lossy behavior. But not everyone <i>cares=
</i> about Unicode support. Some people would rather upgrade when they feel=
the need, rather than just because you added support for something they do=
n't use. And if you talk to your customers about the change and they that s=
till want the old API, or that they a period of compatibility before making=
the change, you shouldn't break them.<br><br>See Python 2 vs 3 as a great =
example of this. Python 3 broke compatibility. And what's the result? Fragm=
entation of the userbase. How many Python-based projects abjectly refuse to=
support 3? Lots. I basically have no choice but to learn Python 2, since f=
ew of the modules I want to use support 3.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>And either cas=
e. This adds to the language, so you can still hold that philosophy and do =
things that way, but everyone else can use a simple syntax.</div></div></bl=
ockquote><div><br>We shouldn't add features to the language that encourage =
bad design decisions. Proper encapsulation allows the designer of the class=
to decide if a change in the implementation must be a breaking change or n=
ot. Improper encapsulation <i>removes</i> this choice; if you change the im=
plementation, even if it <i>could</i> have been compatible, it cannot be.<b=
r></div></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_6_1626659205.1426271802340--
------=_Part_5_1934327013.1426271802340--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 13 Mar 2015 20:46:42 +0200
Raw View
On 13 March 2015 at 20:36, Nicol Bolas <jmckesson@gmail.com> wrote:
> That is complete bunk. Here are several ways of having different
> representations of data, while having the exact same interface. Changing
> from one representation to the other will "break" noone's code.
>
> class Foo
> {
> private:
> std::string name;
>
> public:
> const std::string &GetName() const {return name;}
> };
>
> class Foo
> {
> private:
> uint64_t dbHandle;
> std::shared_ptr<Database> myDb;
>
> public:
> std::string GetName() const {return myDb->AccessField(dbHandle, "name");}
> };
>
> class Foo
> {
> private:
> std::string firstname, lastname;
>
> public:
> std::string GetName() const {return firstname + " " + lastname;}
> }
>
> So there is no validity to your statement that "changing internals will
> break it". At least, not by any reasonable definition of the word "break".
Well, since you started talking about "complete bunk", that last sentence
of yours is exactly that.
--
---
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/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Mar 2015 11:46:59 -0700 (PDT)
Raw View
------=_Part_919_1590211985.1426272419572
Content-Type: multipart/alternative;
boundary="----=_Part_920_1258844980.1426272419572"
------=_Part_920_1258844980.1426272419572
Content-Type: text/plain; charset=UTF-8
What is an "expression alias"? Google seems to have failed me in this
regard.
--
---
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_920_1258844980.1426272419572
Content-Type: text/html; charset=UTF-8
<div dir="ltr">What is an "expression alias"? Google seems to have failed me in this regard.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_920_1258844980.1426272419572--
------=_Part_919_1590211985.1426272419572--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 13 Mar 2015 20:52:12 +0200
Raw View
On 13 March 2015 at 20:46, Nicol Bolas <jmckesson@gmail.com> wrote:
> What is an "expression alias"? Google seems to have failed me in this
> regard.
Well, currently we have type aliases. Various people have floated the idea
of object aliases. Expression aliases are a generalization of object aliases,
since they may or may not be backed by an actual object.
So, in general, you would declare such an expression alias as a member
of your class, and as a strawman syntax, write something _roughly_ like
class X
{
private:
int x_;
public:
using x = const_cast<const int&>(x_);
};
So, any type transformation or any other expression would do. x doesn't consume
any space, since it's just an expression alias that tells the compiler
what expression
to turn x into. Somewhat like a macro, but scoped.
--
---
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/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Fri, 13 Mar 2015 15:05:44 -0400
Raw View
On Fri, Mar 13, 2015 at 2:52 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> class X
> {
> private:
> int x_;
> public:
> using x = const_cast<const int&>(x_);
> };
>
> So, any type transformation or any other expression would do. x doesn't consume
> any space, since it's just an expression alias that tells the compiler
> what expression
> to turn x into. Somewhat like a macro, but scoped.
>
Related proposal:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4147.pdf
However, I'm not sure whether this is enough. For example,
a.x_ gives me lvalue,
std::move(a).x_ gives me prvalue, and allows implicitly moving
from x_.
How do I achieve similar effect with x? Maybe you find my
example boring, but my point is: the expression alias offers
only one type, while I might want it to offer more than one type,
maybe by reacting to && qualifiers, maybe templated (!!), etc.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 13 Mar 2015 15:07:19 -0400
Raw View
On 2015-03-13 13:16, Ville Voutilainen wrote:
> accessor functions or in-class-initialized references provide
> a reasonable solution for many cases that this proposal covers. For the c=
ases
> those solutions don't cover, it seems to me that we should strive for exp=
ression
> aliases, and allow such aliases to be class members.
Yes, please! Provided of course that they can solve the problem.
(Meaning that your point about scoping is critical. Despite that I think
we both agree it would be "wrong", I can nevertheless imagine a "na=C3=AFve=
"
implementation that fails to address this case by being exactly a
glorified PP macro. It's crucial that the expression is evaluated in the
context of the point of definition site rather than point of use.)
That said, can the result type be specified? Or would this use, with
expression aliases, require a cast?
....This reminds me; I'd still like to see 'const <expr>':
class Foo
{
int x_;
public:
using x =3D const x_;
};
--=20
Matthew
--=20
---=20
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 e=
mail 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-proposa=
ls/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Fri, 13 Mar 2015 15:13:18 -0400
Raw View
On Fri, Mar 13, 2015 at 3:07 PM, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
>
> ...This reminds me; I'd still like to see 'const <expr>':
>
> class Foo
> {
> int x_;
>
> public:
> using x = const x_;
> };
>
See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4380.html
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 13 Mar 2015 15:31:04 -0400
Raw View
On 2015-03-13 15:13, Zhihao Yuan wrote:
> On Fri, Mar 13, 2015 at 3:07 PM, Matthew Woehlke wrote:
>>
>> ...This reminds me; I'd still like to see 'const <expr>':
>>
>> class Foo
>> {
>> int x_;
>>
>> public:
>> using x = const x_;
>> };
>
> See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4380.html
From my reading of the Further Discussion, that's all but useless.
(Well, okay, not *useless*... it would work for the above case, but
critically, it would *not* work for the case that I really care about,
which is const-ifying a container in range-based for, which *must* work
for prvalues.)
--
Matthew
--
---
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/.
.
Author: drax325 <draxlerm@gmail.com>
Date: Fri, 13 Mar 2015 13:07:41 -0700 (PDT)
Raw View
------=_Part_472_1273719955.1426277261170
Content-Type: multipart/alternative;
boundary="----=_Part_473_1276707460.1426277261176"
------=_Part_473_1276707460.1426277261176
Content-Type: text/plain; charset=UTF-8
Nicol it gets hard to respond when you speak of so many things. I don't
want to hash this too much.
> My original contention was how you made it sound that encapsulation is the
> only way. My argument is that it is some where in between, which you now
> seem to agree. I think we are just crossing wires on details. Really you
> could make this argument in the discussion of when to use public or private
> variables. My point being you can't say public variables is never a
> reasonable usage. But, adding this readonly adds some protection externally.
>
> By affect the user I mean that the user can no long use the class without
> making changes when using it. Like remove elements or changing types in the
> class would affect the user.
>
I was trying to explain that in situation where you changed the variable
> type, and used hidden conversion that it could lead to problems, which
> affects the user. If a compatibility function was made, compilation
> wouldn't cause error, but other problems due to bad conversions might. And
> I would rather have things break upfront instead of backend. One of my
> points is if you make drastic changes that you should make a new class.
> Just as std::string and std::wstring both exist for the same reason.
> Instead of leaving changing std::string but with wchar implementation. But
> then you have problem of api libriaries, and making sure you have old.lib
> or new.lib and the correct headers depending on which version of the class
> you want. I was making this point based on your unicode example. It's
> debatable when such changes are possible without causing an affect.
>
> Your new example of switching from string to database would be good
> example of how encapsulation would allow for internal change without
> affecting the user if they used an accessor. But they would have problems
> if they use direct access to begin with. But, it hard say how much that
> fundamentally changes how the class works. The problem with this discussion
> is that this feature isn't an option. If people were using the string
> directly, you could just as easily leave the string and update it from the
> database. I'm not going to argue if that is a good idea or not. There are
> too many ways to have code. But, you could preserve compatabiliy without
> causing affect or using encapsulation.
>
--
---
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_473_1276707460.1426277261176
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div> </div><div>Nicol it gets hard to respond when y=
ou speak of so many things. I don't want to hash this too much. =
</div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div>M=
y original contention was how you made it sound that encapsulation is the o=
nly way. My argument is that it is some where in between, which you now see=
m to agree. I think we are just crossing wires on details. Really you=
could make this argument in the discussion of when to use public or privat=
e variables. My point being you can't say public variables is never a reaso=
nable usage. But, adding this readonly adds some protection externally.</di=
v><div><br></div><div>By affect the user I mean that the user can no long u=
se the class without making changes when using it. Like remove elements or =
changing types in the class would affect the user. </div></div></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left=
-style: solid; padding-left: 1ex;"><div dir=3D"ltr">I was trying to explain=
that in situation where you changed the variable type, and used hidden con=
version that it could lead to problems, which affects the user. If a compat=
ibility function was made, compilation wouldn't cause error, but other prob=
lems due to bad conversions might. And I would rather have things break upf=
ront instead of backend. One of my points is if you make drastic changes th=
at you should make a new class. Just as std::string and std::wstring both e=
xist for the same reason. Instead of leaving changing std::string but with =
wchar implementation. But then you have problem of api libriaries, and maki=
ng sure you have old.lib or new.lib and the correct headers depending=
on which version of the class you want. I was making this point based on y=
our unicode example. It's debatable when such changes are possible without =
causing an affect. </div></blockquote><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-c=
olor: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><di=
v dir=3D"ltr"><div><br></div><div>Your new example of switching from string=
to database would be good example of how encapsulation would allow for int=
ernal change without affecting the user if they used an accessor. But they =
would have problems if they use direct access to begin with. But, it hard s=
ay how much that fundamentally changes how the class works. The problem wit=
h this discussion is that this feature isn't an option. If people were usin=
g the string directly, you could just as easily leave the string and update=
it from the database. I'm not going to argue if that is a good idea or not=
.. There are too many ways to have code. But, you could preserve compatabili=
y without causing affect or using encapsulation.</div></div></blockquote></=
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_473_1276707460.1426277261176--
------=_Part_472_1273719955.1426277261170--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Mar 2015 14:53:35 -0700 (PDT)
Raw View
------=_Part_1006_715746425.1426283615069
Content-Type: multipart/alternative;
boundary="----=_Part_1007_1494258128.1426283615069"
------=_Part_1007_1494258128.1426283615069
Content-Type: text/plain; charset=UTF-8
On Friday, March 13, 2015 at 2:46:53 PM UTC-4, Ville Voutilainen wrote:
>
> On 13 March 2015 at 20:36, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > That is complete bunk. Here are several ways of having different
> > representations of data, while having the exact same interface. Changing
> > from one representation to the other will "break" noone's code.
> >
> > class Foo
> > {
> > private:
> > std::string name;
> >
> > public:
> > const std::string &GetName() const {return name;}
> > };
> >
> > class Foo
> > {
> > private:
> > uint64_t dbHandle;
> > std::shared_ptr<Database> myDb;
> >
> > public:
> > std::string GetName() const {return myDb->AccessField(dbHandle,
> "name");}
> > };
> >
> > class Foo
> > {
> > private:
> > std::string firstname, lastname;
> >
> > public:
> > std::string GetName() const {return firstname + " " + lastname;}
> > }
> >
> > So there is no validity to your statement that "changing internals will
> > break it". At least, not by any reasonable definition of the word
> "break".
>
>
> Well, since you started talking about "complete bunk", that last sentence
> of yours is exactly that.
>
Of course, when I "started talking about 'complete bunk'", I actually
followed that by demonstrating why it was "complete bunk".
Unlike you, who simply declared it to be true, thereby adding nothing
useful to the discussion.
Thanks for the effort though.
--
---
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_1007_1494258128.1426283615069
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, March 13, 2015 at 2:46:53 PM UTC-4, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 13 Mar=
ch 2015 at 20:36, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"jP2uCqwtlyAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">jmck...@gmail.com</a>> wrote:
<br>> That is complete bunk. Here are several ways of having different
<br>> representations of data, while having the exact same interface. Ch=
anging
<br>> from one representation to the other will "break" noone's code.
<br>>
<br>> class Foo
<br>> {
<br>> private:
<br>> std::string name;
<br>>
<br>> public:
<br>> const std::string &GetName() const {return name;}
<br>> };
<br>>
<br>> class Foo
<br>> {
<br>> private:
<br>> uint64_t dbHandle;
<br>> std::shared_ptr<Database> myDb;
<br>>
<br>> public:
<br>> std::string GetName() const {return myDb->AccessField(db=
Handle, "name");}
<br>> };
<br>>
<br>> class Foo
<br>> {
<br>> private:
<br>> std::string firstname, lastname;
<br>>
<br>> public:
<br>> std::string GetName() const {return firstname + " " + lastn=
ame;}
<br>> }
<br>>
<br>> So there is no validity to your statement that "changing internals=
will
<br>> break it". At least, not by any reasonable definition of the word =
"break".
<br>
<br>
<br>Well, since you started talking about "complete bunk", that last senten=
ce
<br>of yours is exactly that.
<br></blockquote><div><br>Of course, when I "started talking about 'complet=
e bunk'", I actually followed that by demonstrating why it was "complete bu=
nk".<br><br>Unlike you, who simply declared it to be true, thereby adding n=
othing useful to the discussion.<br><br>Thanks for the effort though.<br></=
div></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_1007_1494258128.1426283615069--
------=_Part_1006_715746425.1426283615069--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 13 Mar 2015 23:55:37 +0200
Raw View
On 13 March 2015 at 23:53, Nicol Bolas <jmckesson@gmail.com> wrote:
> Of course, when I "started talking about 'complete bunk'", I actually
> followed that by demonstrating why it was "complete bunk".
By showing the examples where changing the internal representation
actually breaks the code that uses those types, if compiled separately?
You demonstrated quite the opposite of what you intended.
--
---
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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 13 Mar 2015 15:04:37 -0700
Raw View
On Friday 13 March 2015 23:55:37 Ville Voutilainen wrote:
> On 13 March 2015 at 23:53, Nicol Bolas <jmckesson@gmail.com> wrote:
> > Of course, when I "started talking about 'complete bunk'", I actually
> > followed that by demonstrating why it was "complete bunk".
>
> By showing the examples where changing the internal representation
> actually breaks the code that uses those types, if compiled separately?
> You demonstrated quite the opposite of what you intended.
We need to qualify the breakage. Is it a source compatibility issue or a
binary compatibility issue?
The examples in Nicol's post break binary compatibility but they do keep
source compatibility. So a simple recompile should allow applications to use
the new version. That may not be an option to all users, but if Boost can get
away with doing it every single release, it must work for a lot of people.
In contrast, source compatibility issues, such as what you're talking about
there, require not only a recompilation, but also to change the source code to
deal with the fact that things change. Those have a much higher cost than
binary breaks, since you need to inspect every change and revalidate.
Take this example from Nicol:
> class ReadOnly
> {
>
> public:
>
> read:
> std::string name;
>
> };
> class ReadOnly
> {
>
> public:
>
> read:
> UnicodeString name;
>
> };
>
> Even if UnicodeString had a completely identical interface to std::string
> (and it would be a horrible UnicodeString if it did), you've still broken
> every user of your 'name' field. They all must update to use your
> UnicodeString type. Oh sure, liberal use of 'auto' can minimize that to a
> degree. But it won't stop people who do "obj.name.c_str();" from failing.
The above is definitely a binary incompatible change.
With some care, it can be made source compatible, but it often won't be. The
example of calling c_str() is a good example: you may not be able to return a
persistent pointer to internally-stored data.
Though in my opinion, from experience, the only thing worse than source
incompatible breakages are *silent* source incompatibilities. You won't notice
when porting your software. You'll notice when you get a bug report from the
field.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Mar 2015 15:53:00 -0700 (PDT)
Raw View
------=_Part_1048_1202591500.1426287180137
Content-Type: multipart/alternative;
boundary="----=_Part_1049_1986738583.1426287180137"
------=_Part_1049_1986738583.1426287180137
Content-Type: text/plain; charset=UTF-8
On Friday, March 13, 2015 at 6:04:42 PM UTC-4, Thiago Macieira wrote:
>
> The above is definitely a binary incompatible change.
>
> With some care, it can be made source compatible, but it often won't be.
> The
> example of calling c_str() is a good example: you may not be able to
> return a
> persistent pointer to internally-stored data.
>
I contest this... in part.
While it is certainly legal to store the pointer returned by .c_str() for
the duration of Foo's lifetime, the *validity* of that pointer cannot be
determined. Because any of Foo's non-const functions could cause a
re-allocation that invalidates this pointer, there is no expectation that
the user could rely on storing that pointer long-term. That's just a part
of std::string's API.
So storing the pointer long-term represents highly dubious and potentially
dangerous code. Granted, changing the return type to a value means that you
can't even do GetName().c_str() and use it outside of that expression. So
even some things that were protected behavior became unprotected.
But I'd say that the problem isn't really .c_str(). The problem is that you
could keep that reference to the std::string around for just as long as
Foo. You can store it in some other object and keep it there. And so long
as Foo exists, so too will that reference. When Foo updates the string, the
reference will see it. That's the promise made by returning a const&.
When it changes to a value, the promise is broken.
That creates an interesting tension with accessors. On the one hand, you
usually return members by const& if they're not going to be able to change
them. But if the idea is that the return value is ephemeral, if the
lifetime of the memory in that object should not be connected to the object
returning it, then a value should be used. But... that's throwing
performance away in the original case, since you're copying something when
the user doesn't (necessarily) need it to be copied. And you certainly
can't move it, since you still need to keep it.
And it's not like the problem is limited to std::string. This happens with
anything that has a const function that returns a const-reference to
something inside itself.
There's no effective language solution to this problem. So the only thing I
could imagine is a solution of convention. Therefore by convention, it is
inappropriate to write code that relies upon a return value being a
reference to internal objects rather than ephemeral ones, with the
exception of certain very specific cases. I would hope that people would
follow such a recommendation.
That being said, "hope" has never been an effective strategy for upgrading
software ;)
--
---
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_1049_1986738583.1426287180137
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 13, 2015 at 6:04:42 PM UTC-4, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The above is defini=
tely a binary incompatible change.
<br>
<br>With some care, it can be made source compatible, but it often won't be=
.. The=20
<br>example of calling c_str() is a good example: you may not be able to re=
turn a=20
<br>persistent pointer to internally-stored data.
<br></blockquote><div><br>I contest this... in part.<br><br>While it is cer=
tainly legal to store the pointer returned by .c_str() for the duration of =
Foo's lifetime, the <i>validity</i> of that pointer cannot be determined. B=
ecause any of Foo's non-const functions could cause a re-allocation that in=
validates this pointer, there is no expectation that the user could rely on=
storing that pointer long-term. That's just a part of std::string's API.<b=
r><br>So storing the pointer long-term represents highly dubious and potent=
ially dangerous code. Granted, changing the return type to a value means th=
at you can't even do GetName().c_str() and use it outside of that expressio=
n. So even some things that were protected behavior became unprotected.<br>=
<br>But I'd say that the problem isn't really .c_str(). The problem is that=
you could keep that reference to the std::string around for just as long a=
s Foo. You can store it in some other object and keep it there. And so long=
as Foo exists, so too will that reference. When Foo updates the string, th=
e reference will see it. That's the promise made by returning a const&.=
<br><br>When it changes to a value, the promise is broken.<br><br>That crea=
tes an interesting tension with accessors. On the one hand, you usually ret=
urn members by const& if they're not going to be able to change them. B=
ut if the idea is that the return value is ephemeral, if the lifetime of th=
e memory in that object should not be connected to the object returning it,=
then a value should be used. But... that's throwing performance away in th=
e original case, since you're copying something when the user doesn't (nece=
ssarily) need it to be copied. And you certainly can't move it, since you s=
till need to keep it.<br><br>And it's not like the problem is limited to st=
d::string. This happens with anything that has a const function that return=
s a const-reference to something inside itself.</div><br>There's no effecti=
ve language solution to this problem. So the only thing I could imagine is =
a solution of convention. Therefore by convention, it is inappropriate to w=
rite code that relies upon a return value being a reference to internal obj=
ects rather than ephemeral ones, with the exception of certain very specifi=
c cases. I would hope that people would follow such a recommendation.<br><b=
r>That being said, "hope" has never been an effective strategy for upgradin=
g software ;)<br></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_1049_1986738583.1426287180137--
------=_Part_1048_1202591500.1426287180137--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 13 Mar 2015 19:29:52 -0700
Raw View
On Friday 13 March 2015 15:53:00 Nicol Bolas wrote:
> On Friday, March 13, 2015 at 6:04:42 PM UTC-4, Thiago Macieira wrote:
> > The above is definitely a binary incompatible change.
> >
> > With some care, it can be made source compatible, but it often won't be.
> > The
> > example of calling c_str() is a good example: you may not be able to
> > return a
> > persistent pointer to internally-stored data.
>
> I contest this... in part.
>
> While it is certainly legal to store the pointer returned by .c_str() for
> the duration of Foo's lifetime, the *validity* of that pointer cannot be
> determined. Because any of Foo's non-const functions could cause a
> re-allocation that invalidates this pointer, there is no expectation that
> the user could rely on storing that pointer long-term. That's just a part
> of std::string's API.
We're not talking about std::string::c_str(). We're talking about
UnicodeString::c_str() here, for an undefined implementation of UnicodeString.
The point is that UnicodeString may be unable to have the same guarantees as
std::string::c_str().
This is valid:
std::string foo = getString();
const char *ptr = foo.c_str();
use(ptr);
This may not be:
UnicodeString foo = getString();
const char *ptr = foo.c_str();
use(ptr);
> That creates an interesting tension with accessors. On the one hand, you
> usually return members by const& if they're not going to be able to change
> them.
Not really. You usually return them by value, unless the objective is to
return a non-const reference to some modifiable data.
> But if the idea is that the return value is ephemeral, if the
> lifetime of the memory in that object should not be connected to the object
> returning it, then a value should be used. But... that's throwing
> performance away in the original case, since you're copying something when
> the user doesn't (necessarily) need it to be copied. And you certainly
> can't move it, since you still need to keep it.
Just make sure you're using classes that do cheap copies.
(you're usually trading that off for something else)
> And it's not like the problem is limited to std::string. This happens with
> anything that has a const function that returns a const-reference to
> something inside itself.
Right, which is why you should avoid it in API that intends to retain
compatibility for extended period of time while still allowing for constant
improvements to the internals. Instead, return by value.
> There's no effective language solution to this problem. So the only thing I
> could imagine is a solution of convention. Therefore by convention, it is
> inappropriate to write code that relies upon a return value being a
> reference to internal objects rather than ephemeral ones, with the
> exception of certain very specific cases. I would hope that people would
> follow such a recommendation.
>
> That being said, "hope" has never been an effective strategy for upgrading
> software ;)
No doubt.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 14 Mar 2015 08:28:55 -0700 (PDT)
Raw View
------=_Part_2045_1843448892.1426346935849
Content-Type: multipart/alternative;
boundary="----=_Part_2046_1098952575.1426346935849"
------=_Part_2046_1098952575.1426346935849
Content-Type: text/plain; charset=UTF-8
On Friday, March 13, 2015 at 7:36:42 PM UTC+1, Nicol Bolas wrote:
>
> const std::string &GetName() const {return name;}
> std::string GetName() const {return myDb->AccessField(dbHandle, "name");}
>
Are you sure these two are equivalent? ;)
IMO having public const access to members would be nice. It might break
encapsulation but that SHOULD be the choice of the developer.
--
---
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_2046_1098952575.1426346935849
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, March 13, 2015 at 7:36:42 PM UTC+1, Nicol Bolas=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>&=
nbsp; const std::string &GetName() const {return name;}<br> std::=
string GetName() const {return myDb->AccessField(dbHandle, "name");}<br>=
</div></div></blockquote><div><br></div><div>Are you sure these two are equ=
ivalent? ;)</div><div><br></div><div>IMO having public const access to memb=
ers would be nice. It might break encapsulation but that SHOULD be the choi=
ce of the developer.</div></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_2046_1098952575.1426346935849--
------=_Part_2045_1843448892.1426346935849--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 14 Mar 2015 08:35:02 -0700 (PDT)
Raw View
------=_Part_1754_1782843766.1426347302026
Content-Type: multipart/alternative;
boundary="----=_Part_1755_415848571.1426347302026"
------=_Part_1755_415848571.1426347302026
Content-Type: text/plain; charset=UTF-8
On Friday, March 13, 2015 at 7:52:13 PM UTC+1, Ville Voutilainen wrote:
>
> On 13 March 2015 at 20:46, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > What is an "expression alias"? Google seems to have failed me in this
> > regard.
>
>
> Well, currently we have type aliases. Various people have floated the idea
> of object aliases. Expression aliases are a generalization of object
> aliases,
> since they may or may not be backed by an actual object.
>
> So, in general, you would declare such an expression alias as a member
> of your class, and as a strawman syntax, write something _roughly_ like
>
> class X
> {
> private:
> int x_;
> public:
> using x = const_cast<const int&>(x_);
> };
>
> So, any type transformation or any other expression would do. x doesn't
> consume
> any space, since it's just an expression alias that tells the compiler
> what expression
> to turn x into. Somewhat like a macro, but scoped.
>
Duplicating all such members (and types) is not okay IMO.
Do we still not have as_const BTW?
--
---
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_1755_415848571.1426347302026
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, March 13, 2015 at 7:52:13 PM UTC+1, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 13 Mar=
ch 2015 at 20:46, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"YVAnMa0rPFsJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">jmck...@gmail.com</a>> wrote:
<br>> What is an "expression alias"? Google seems to have failed me in t=
his
<br>> regard.
<br>
<br>
<br>Well, currently we have type aliases. Various people have floated the i=
dea
<br>of object aliases. Expression aliases are a generalization of object al=
iases,
<br>since they may or may not be backed by an actual object.
<br>
<br>So, in general, you would declare such an expression alias as a member
<br>of your class, and as a strawman syntax, write something _roughly_ like
<br>
<br>class X
<br>{
<br>private:
<br> int x_;
<br>public:
<br> using x =3D const_cast<const int&>(x_);
<br>};
<br>
<br>So, any type transformation or any other expression would do. x doesn't=
consume
<br>any space, since it's just an expression alias that tells the compiler
<br>what expression
<br>to turn x into. Somewhat like a macro, but scoped.
<br></blockquote><div><br></div><div>Duplicating all such members (and type=
s) is not okay IMO. </div><div>Do we still not have as_const BTW?</div=
></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_1755_415848571.1426347302026--
------=_Part_1754_1782843766.1426347302026--
.
Author: drax325 <draxlerm@gmail.com>
Date: Sat, 14 Mar 2015 08:40:13 -0700 (PDT)
Raw View
------=_Part_10_977632598.1426347613720
Content-Type: multipart/alternative;
boundary="----=_Part_11_673691389.1426347613720"
------=_Part_11_673691389.1426347613720
Content-Type: text/plain; charset=UTF-8
>>On Friday, March 13, 2015 at 5:53:00 PM UTC-5, Nicol Bolas wrote:
>>While it is certainly legal to store the pointer returned by .c_str() for
the duration of Foo's lifetime, the validity of that pointer cannot be
determined.
This is a tangent, but this statement is true in a general sense. There is
always a problem when using copies of data that are mutable. This can be
even worse if you have a volatile region with multiple threading, or worse
race conditions and hopefully, that would be avoided.
Copies of const are fine until you add const conversions, then you won't
know if it is mutable. Otherwise if not const you just need to use all
copies mostly immediately.
Which leads to an interesting idea though I don't know how it could be
implement, but like a self destructing copy. Maybe be able to undeclare
variables. But, then you should just use scoping. And if the copy could
know the original was modified, but that I think would need to having weird
linkage, monitoring, and be runtime mechanism so no good. It might not
work, but I still think it is interesting.
--
---
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_11_673691389.1426347613720
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>>>On Friday, March 13, 2015 at 5=
:53:00 PM UTC-5, Nicol Bolas wrote:</div><div>>>While it is certainly=
legal to store the pointer returned by .c_str() for the duration of Foo's =
lifetime, the validity of that pointer cannot be determined.</div><div><br>=
</div><div>This is a tangent, but this statement is true in a general sense=
.. There is always a problem when using copies of data that are mutable. Thi=
s can be even worse if you have a volatile region with multiple threading, =
or worse race conditions and hopefully, that would be avoided. </div><=
div><br></div><div>Copies of const are fine until you add const conversions=
, then you won't know if it is mutable. Otherwise if not const you just nee=
d to use all copies mostly immediately.</div><div><br></div><div>Which lead=
s to an interesting idea though I don't know how it could be implement, but=
like a self destructing copy. Maybe be able to undeclare variables. But, t=
hen you should just use scoping. And if the copy could know the original wa=
s modified, but that I think would need to having weird linkage, monitoring=
, and be runtime mechanism so no good. It might not work, but I still think=
it is interesting. </div></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_11_673691389.1426347613720--
------=_Part_10_977632598.1426347613720--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 14 Mar 2015 17:41:02 +0200
Raw View
On 14 March 2015 at 17:35, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> Well, currently we have type aliases. Various people have floated the idea
>> of object aliases. Expression aliases are a generalization of object
>> aliases,
>> since they may or may not be backed by an actual object.
>>
>> So, in general, you would declare such an expression alias as a member
>> of your class, and as a strawman syntax, write something _roughly_ like
>>
>> class X
>> {
>> private:
>> int x_;
>> public:
>> using x = const_cast<const int&>(x_);
>> };
>>
>> So, any type transformation or any other expression would do. x doesn't
>> consume
>> any space, since it's just an expression alias that tells the compiler
>> what expression
>> to turn x into. Somewhat like a macro, but scoped.
> Duplicating all such members (and types) is not okay IMO.
Duplicating? You would have to opt-in to a "read:" too, although that's perhaps
less code to write.
Now, to get back to api/abi-stability, not even expression aliases are immune to
such concerns - quite the opposite - they are more or less inline
code, so changes
to that code is an abi break.
Even so, I do not see read: as a feature important enough to
standardize. Even if
alternatives cause more 'duplication', that's fine by me. I don't have
any evidence
for read: being an important feature to have to begin with.
> Do we still not have as_const BTW?
It's in a recent mailing, but hasn't been adopted yet.
--
---
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/.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 14 Mar 2015 16:45:24 +0100
Raw View
2015-03-14 16:41 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 14 March 2015 at 17:35, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> Well, currently we have type aliases. Various people have floated the idea
>>> of object aliases. Expression aliases are a generalization of object
>>> aliases,
>>> since they may or may not be backed by an actual object.
>>>
>>> So, in general, you would declare such an expression alias as a member
>>> of your class, and as a strawman syntax, write something _roughly_ like
>>>
>>> class X
>>> {
>>> private:
>>> int x_;
>>> public:
>>> using x = const_cast<const int&>(x_);
>>> };
>>>
>>> So, any type transformation or any other expression would do. x doesn't
>>> consume
>>> any space, since it's just an expression alias that tells the compiler
>>> what expression
>>> to turn x into. Somewhat like a macro, but scoped.
>> Duplicating all such members (and types) is not okay IMO.
>
> Duplicating?
What's the question?
> You would have to opt-in to a "read:" too, although that's perhaps
> less code to write.
Probably and it doesn't require you to repeat the members. Your code
also uses two names for one member and IMO a bare x is not acceptable
as member variable name.
> Now, to get back to api/abi-stability, not even expression aliases are immune to
> such concerns - quite the opposite - they are more or less inline
> code, so changes
> to that code is an abi break.
Stable C++ ABIs are always problematic.
> Even so, I do not see read: as a feature important enough to
> standardize. Even if
> alternatives cause more 'duplication', that's fine by me. I don't have
> any evidence
> for read: being an important feature to have to begin with.
It's a 'lite' implementation of properties and AFAIK properties come
up time and time again.
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 14 Mar 2015 17:57:48 +0200
Raw View
On 14 March 2015 at 17:45, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> Duplicating all such members (and types) is not okay IMO.
>> Duplicating?
> What's the question?
The real question is whether that's a problem - would you really
expose every member
that way?
>> You would have to opt-in to a "read:" too, although that's perhaps
>> less code to write.
> Probably and it doesn't require you to repeat the members. Your code
> also uses two names for one member and IMO a bare x is not acceptable
> as member variable name.
It uses two names for different things. One is the internal modifiable name,
the other is a const public name.
> It's a 'lite' implementation of properties and AFAIK properties come
> up time and time again.
And they get rejected time and again. They don't even get as far as an actual
proposal, but there sure is a lot of talk every time a new person thinks they
are a good idea. And, seemingly, none of the new discussions manage to
solve the reasons why properties have been rejected before, especially
the reason that their motivation is, after all, weak - since it
apparently boils down to
not wanting to change clients that use non-function syntax when an
actual function
becomes necessary. There are numerous people who will reject
properties based on that
alone.
--
---
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/.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 14 Mar 2015 17:12:04 +0100
Raw View
2015-03-14 16:57 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 14 March 2015 at 17:45, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>>> Duplicating all such members (and types) is not okay IMO.
>>> Duplicating?
>> What's the question?
>
> The real question is whether that's a problem - would you really
> expose every member
> that way?
Not in all cases but that doesn't mean duplication is not a problem.
>>> You would have to opt-in to a "read:" too, although that's perhaps
>>> less code to write.
>> Probably and it doesn't require you to repeat the members. Your code
>> also uses two names for one member and IMO a bare x is not acceptable
>> as member variable name.
>
> It uses two names for different things. One is the internal modifiable name,
> the other is a const public name.
Sure, but there's no real need for two names is there?
>> It's a 'lite' implementation of properties and AFAIK properties come
>> up time and time again.
>
> And they get rejected time and again.
Are they?
I don't remember seeing solid reasons against the concept.
> They don't even get as far as an actual
> proposal, but there sure is a lot of talk every time a new person thinks they
> are a good idea. And, seemingly, none of the new discussions manage to
> solve the reasons why properties have been rejected before, especially
> the reason that their motivation is, after all, weak - since it
> apparently boils down to
> not wanting to change clients that use non-function syntax when an
> actual function
> becomes necessary. There are numerous people who will reject
> properties based on that
> alone.
Lots of function calls in C++ are implicit so I don't get how that's
an actual argument.
--
Olaf
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 14 Mar 2015 18:19:37 +0200
Raw View
On 14 March 2015 at 18:12, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> The real question is whether that's a problem - would you really
>> expose every member
>> that way?
> Not in all cases but that doesn't mean duplication is not a problem.
That also doesn't mean that it's a significant problem.
>> It uses two names for different things. One is the internal modifiable name,
>> the other is a const public name.
> Sure, but there's no real need for two names is there?
Perhaps not. Such aliases could be defined so that they will not refer
themselves.
But how would internal uses know not to use the alias, if it has the same name
as a member?
>>> It's a 'lite' implementation of properties and AFAIK properties come
>>> up time and time again.
>> And they get rejected time and again.
> Are they?
Are they not?
> I don't remember seeing solid reasons against the concept.
I don't remember seeing solid motivation for properties. The onus is on the
people who want it to rationalize why.
>> the reason that their motivation is, after all, weak - since it
>> apparently boils down to
>> not wanting to change clients that use non-function syntax when an
>> actual function
>> becomes necessary. There are numerous people who will reject
>> properties based on that
>> alone.
> Lots of function calls in C++ are implicit so I don't get how that's
> an actual argument.
Member access expressions aren't, so making them potentially implicit function
calls is a reasonable concern. If you don't get that, I suggest you
talk to people
who see that as a significant problem, because I'm not one of them, so I'm the
wrong person to explain their motivation.
--
---
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/.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 14 Mar 2015 17:31:44 +0100
Raw View
2015-03-14 17:19 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 14 March 2015 at 18:12, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>> The real question is whether that's a problem - would you really
>>> expose every member
>>> that way?
>> Not in all cases but that doesn't mean duplication is not a problem.
>
> That also doesn't mean that it's a significant problem.
AFAIK duplication is a real problem.
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
>>> It uses two names for different things. One is the internal modifiable name,
>>> the other is a const public name.
>> Sure, but there's no real need for two names is there?
>
> Perhaps not. Such aliases could be defined so that they will not refer
> themselves.
> But how would internal uses know not to use the alias, if it has the same name
> as a member?
It's a problem caused by your solution, it's not inherent to the
requested functionality.
>>>> It's a 'lite' implementation of properties and AFAIK properties come
>>>> up time and time again.
>>> And they get rejected time and again.
>> Are they?
>
> Are they not?
Depends on the definition of rejection I guess. Lots of people do
claim it can be implemented in libraries or that it's not necessary
etc but AFAIK a library-based implemenation isn't available.
>> I don't remember seeing solid reasons against the concept.
>
> I don't remember seeing solid motivation for properties. The onus is on the
> people who want it to rationalize why.
You might be right here.
>>> the reason that their motivation is, after all, weak - since it
>>> apparently boils down to
>>> not wanting to change clients that use non-function syntax when an
>>> actual function
>>> becomes necessary. There are numerous people who will reject
>>> properties based on that
>>> alone.
>> Lots of function calls in C++ are implicit so I don't get how that's
>> an actual argument.
>
> Member access expressions aren't, so making them potentially implicit function
> calls is a reasonable concern. If you don't get that, I suggest you
> talk to people
> who see that as a significant problem, because I'm not one of them, so I'm the
> wrong person to explain their motivation.
--
Olaf
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 14 Mar 2015 18:37:27 +0200
Raw View
On 14 March 2015 at 18:31, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> 2015-03-14 17:19 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
>> On 14 March 2015 at 18:12, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>>> The real question is whether that's a problem - would you really
>>>> expose every member
>>>> that way?
>>> Not in all cases but that doesn't mean duplication is not a problem.
>>
>> That also doesn't mean that it's a significant problem.
>
> AFAIK duplication is a real problem.
That depends on how often you actually would want to have a different name
for the public name, and when you'd want to use the same name.
>>>> It uses two names for different things. One is the internal modifiable name,
>>>> the other is a const public name.
>>> Sure, but there's no real need for two names is there?
>>
>> Perhaps not. Such aliases could be defined so that they will not refer
>> themselves.
>> But how would internal uses know not to use the alias, if it has the same name
>> as a member?
>
> It's a problem caused by your solution, it's not inherent to the
> requested functionality.
Yes, the solution I mentioned as a possible solution is more general,
and is less
optimal for the case of requested functionality. The original request suggests
using a label that looks like an access label, and it's very clear to me whether
the original request is important and common enough to have such a syntax
for its specific functionality - the answer to that is NO. Hence I'm considering
more general facilities that would reasonably implement the requested
functionality.
Whether such general facilities are attainable is a separate matter. I am fairly
confident a 'read:' label will be rejected.
--
---
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/.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 14 Mar 2015 17:41:25 +0100
Raw View
2015-03-14 17:37 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
>> AFAIK duplication is a real problem.
>
> That depends on how often you actually would want to have a different name
> for the public name, and when you'd want to use the same name.
AFAIK you'd almost always want the same name but your solution
requires a different name doesn't it?
>> It's a problem caused by your solution, it's not inherent to the
>> requested functionality.
>
> Yes, the solution I mentioned as a possible solution is more general,
> and is less
> optimal for the case of requested functionality. The original request suggests
> using a label that looks like an access label, and it's very clear to me whether
> the original request is important and common enough to have such a syntax
> for its specific functionality - the answer to that is NO. Hence I'm considering
> more general facilities that would reasonably implement the requested
> functionality.
> Whether such general facilities are attainable is a separate matter. I am fairly
> confident a 'read:' label will be rejected.
Sure, but that doesn't mean the original problem is 'invalid'. I think
it'd be nice to at least acknowledge the original concern / problem.
--
Olaf
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 14 Mar 2015 18:47:01 +0200
Raw View
On 14 March 2015 at 18:41, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> 2015-03-14 17:37 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
>>> AFAIK duplication is a real problem.
>>
>> That depends on how often you actually would want to have a different name
>> for the public name, and when you'd want to use the same name.
>
> AFAIK you'd almost always want the same name but your solution
> requires a different name doesn't it?
I suppose it's possible to use the same name, but that name would shadow
the underlying one. ;) I'm not so sure whether you'd almost always really use
the same name.
>> Whether such general facilities are attainable is a separate matter. I am fairly
>> confident a 'read:' label will be rejected.
> Sure, but that doesn't mean the original problem is 'invalid'. I think
> it'd be nice to at least acknowledge the original concern / problem.
Oh, I don't think I ever said it's invalid. Whether it's significant
enough to require
a language solution to solve is another matter. Based on the things I've seen,
I am rather unconvinced that such a thing needs a language solution - it doesn't
seem like a common enough problem for that.
--
---
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/.
.
Author: drax325 <draxlerm@gmail.com>
Date: Sat, 14 Mar 2015 09:56:24 -0700 (PDT)
Raw View
------=_Part_1178_984896724.1426352184552
Content-Type: multipart/alternative;
boundary="----=_Part_1179_1989544482.1426352184552"
------=_Part_1179_1989544482.1426352184552
Content-Type: text/plain; charset=UTF-8
On Saturday, March 14, 2015 at 11:37:28 AM UTC-5, Ville Voutilainen wrote:
>Whether such general facilities are attainable is a separate matter. I am
fairly
>confident a 'read:' label will be rejected.
Yes it only applies to a single case, but which aids in creating a simple
syntax for it. I think it maybe able problem of adding it too late to the
language. You could probably make similar argument against 'const' , yes it
helps in optimizing, but for the programming is just a safety feature and
you could say the onus is on the programmer to be safe.
It's a good point in having a general solution with aliasing. I do think,
the repeating naming structure is unfavorable. It is like having a virtual
const reference ( reference with no memory). Having several references to
the same variable in the same scope wouldn't seem necessary; but, that
isn't not allow either.
But, I fail to see how aliasing can be applied generally with expressions.
Would it just be a non-function syntax for inlining?
--
---
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_1179_1989544482.1426352184552
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, March 14, 2015 at 11:37:28 AM UTC-5, =
Ville Voutilainen wrote:<div>>Whether such general facilities are attain=
able is a separate matter. I am fairly </div><div>>confident a 'rea=
d:' label will be rejected. </div><div><br></div><div>Yes it only appl=
ies to a single case, but which aids in creating a simple syntax for it. I =
think it maybe able problem of adding it too late to the language. You coul=
d probably make similar argument against 'const' , yes it helps in optimizi=
ng, but for the programming is just a safety feature and you could say the =
onus is on the programmer to be safe.</div><div><br></div><div>It's a good =
point in having a general solution with aliasing. I do think, the repeating=
naming structure is unfavorable. It is like having a virtual const referen=
ce ( reference with no memory). Having several references to the same varia=
ble in the same scope wouldn't seem necessary; but, that isn't not al=
low either.</div><div><br></div><div>But, I fail to see how aliasing can be=
applied generally with expressions. Would it just be a non-function syntax=
for inlining? </div><div><br></div><div><br></div></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_1179_1989544482.1426352184552--
------=_Part_1178_984896724.1426352184552--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 14 Mar 2015 19:05:17 +0200
Raw View
On 14 March 2015 at 18:56, drax325 <draxlerm@gmail.com> wrote:
>>Whether such general facilities are attainable is a separate matter. I am
>> fairly
>>confident a 'read:' label will be rejected.
> Yes it only applies to a single case, but which aids in creating a simple
> syntax for it. I think it maybe able problem of adding it too late to the
> language. You could probably make similar argument against 'const' , yes it
> helps in optimizing, but for the programming is just a safety feature and
> you could say the onus is on the programmer to be safe.
I don't see the analogy for const. A read: label has alternatives, like defining
accessor functions from the very beginning. It's like properties - the
motivation
for the facility seems to be that it's a non-intrusive way to add protection
after releasing a class that has no protection, and wanting to add
that protection
without requiring clients to change the syntax they use(*, see below).
> It's a good point in having a general solution with aliasing. I do think,
> the repeating naming structure is unfavorable. It is like having a virtual
> const reference ( reference with no memory). Having several references to
> the same variable in the same scope wouldn't seem necessary; but, that
> isn't not allow either.
I don't quite follow what you're trying to say here...
> But, I fail to see how aliasing can be applied generally with expressions.
> Would it just be a non-function syntax for inlining?
Yes, it's a case of (*) mentioned above, more or less. It would allow changing
what an id-expression means. That would certainly be useful and powerful,
but there are audiences who don't like such things. It's very much like a macro,
except it obeys scope and is more (or less, depending on your point of view :) )
than just a textual replacement.
--
---
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/.
.
Author: drax325 <draxlerm@gmail.com>
Date: Sat, 14 Mar 2015 10:28:59 -0700 (PDT)
Raw View
------=_Part_32_387051214.1426354139468
Content-Type: multipart/alternative;
boundary="----=_Part_33_441786935.1426354139468"
------=_Part_33_441786935.1426354139468
Content-Type: text/plain; charset=UTF-8
On Saturday, March 14, 2015 at 12:05:19 PM UTC-5, Ville Voutilainen wrote:
>
> On 14 March 2015 at 18:56, drax325 <drax...@gmail.com <javascript:>>
> wrote:
> >>Whether such general facilities are attainable is a separate matter. I
> am
> >> fairly
> >>confident a 'read:' label will be rejected.
> > Yes it only applies to a single case, but which aids in creating a
> simple
> > syntax for it. I think it maybe able problem of adding it too late to
> the
> > language. You could probably make similar argument against 'const' , yes
> it
> > helps in optimizing, but for the programming is just a safety feature
> and
> > you could say the onus is on the programmer to be safe.
>
> >I don't see the analogy for const. A read: label has alternatives, like
> defining
> >accessor functions from the very beginning. It's like properties - the
> >motivation
> >for the facility seems to be that it's a non-intrusive way to add
> protection
> >after releasing a class that has no protection, and wanting to add
> >that protection
> >without requiring clients to change the syntax they use(*, see below).
>
I was meaning the simple syntax of const, only applies to a single case,
and you could say is not necessary. But, yes unlike const which has no
alternative. This has functions, but that has the function overhead though
minimal. I think it is still debatable if being able to change what you are
getting from the class is a good thing. The class writer shouldn't be malus
though unlikely.
> > It's a good point in having a general solution with aliasing. I do
> think,
> > the repeating naming structure is unfavorable. It is like having a
> virtual
> > const reference ( reference with no memory). Having several references
> to
> > the same variable in the same scope wouldn't seem necessary; but, that
> > isn't not allow either.
>
>I don't quite follow what you're trying to say here...
>
I was going on tangent midstream. I agree with what was said prior, the
problem of having two names for the same thing as with your syntax, seeming
to be unnecessary. And I extended that further if you had multiple
references in same scope to same memory, you wouldn't need such a thing,
unless you like to be obfuscatory and confused.
I think though this idea of syntax might work.
virtual <type> &<name> = (aliased expression)
--
---
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_33_441786935.1426354139468
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, March 14, 2015 at 12:05:19 PM UTC-5, =
Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 14 =
March 2015 at 18:56, drax325 <<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"RVh-V05R0pwJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">drax...@gmail.com</a>> wrote:
<br>>>Whether such general facilities are attainable is a separate ma=
tter. I am
<br>>> fairly
<br>>>confident a 'read:' label will be rejected.
<br>> Yes it only applies to a single case, but which aids in creating a=
simple
<br>> syntax for it. I think it maybe able problem of adding it too late=
to the
<br>> language. You could probably make similar argument against 'const'=
, yes it
<br>> helps in optimizing, but for the programming is just a safety feat=
ure and
<br>> you could say the onus is on the programmer to be safe.
<br>
<br>>I don't see the analogy for const. A read: label has alternatives, =
like defining
<br>>accessor functions from the very beginning. It's like properties - =
the
<br>>motivation
<br>>for the facility seems to be that it's a non-intrusive way to add p=
rotection
<br>>after releasing a class that has no protection, and wanting to add
<br>>that protection
<br>>without requiring clients to change the syntax they use(*, see belo=
w).
<br></blockquote><div><br></div><div>I was meaning the simple syntax of con=
st, only applies to a single case, and you could say is not necessary. But,=
yes unlike const which has no alternative. This has functions, but that ha=
s the function overhead though minimal. I think it is still debatable if be=
ing able to change what you are getting from the class is a good thing. The=
class writer shouldn't be malus though unlikely.</div><div> </div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">> It's a good point in having =
a general solution with aliasing. I do think,
<br>> the repeating naming structure is unfavorable. It is like having a=
virtual
<br>> const reference ( reference with no memory). Having several refere=
nces to
<br>> the same variable in the same scope wouldn't seem necessary;  =
;but, that
<br>> isn't not allow either. </blockquote><div> </div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"> </blockquote><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">>I don't quite follow what you're trying to say he=
re...
<br></blockquote><div><br></div><div>I was going on tangent midstream. I ag=
ree with what was said prior, the problem of having two names for the same =
thing as with your syntax, seeming to be unnecessary. And I extended that f=
urther if you had multiple references in same scope to same memory, you wou=
ldn't need such a thing, unless you like to be obfuscatory and confused.</d=
iv><div> </div><div>I think though this idea of syntax might work.</di=
v><div>virtual <type> &<name> =3D (aliased expression=
)</div></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_33_441786935.1426354139468--
------=_Part_32_387051214.1426354139468--
.