Topic: implicit parent reference
Author: gmisocpp@gmail.com
Date: Sun, 4 Jan 2015 22:23:17 -0800 (PST)
Raw View
------=_Part_230_223272727.1420438997332
Content-Type: multipart/alternative;
boundary="----=_Part_231_890791380.1420438997332"
------=_Part_231_890791380.1420438997332
Content-Type: text/plain; charset=UTF-8
I haven't thought this through too much, but I was thinking..
Some objects are not meant to be used independent of their parent object.
In such designs the sub object sometimes retains a pointer to the parent
object.
Often such a pointer is undesriable because of space efficiency or whatever.
But if one doesn't hold a back pointer, supplying a parent object to a
function on the sub object that needs it needs is tedious.
What if C++ had a feature to provide the parent of an expression implicitly
to the subobect or something like that.
With other extensions, this idea or a variation on the theme might also
enable a kind of "properties" proposal amongst other things so I'm using
that as a contrived example of the feature.
I wonder if it might be useful to the range proposal too in some way but I
haven't considered that at all.
// Contrived uncompilable example:
x_prop.h
#include "window.h"
class x_prop
{
int x_;
public:
x_prop() {}
void operator = (parent Window& w, int x);
void operator += (parent Window& w, int x);
int operator () { return _x; };
};
x_prop.cpp
void x_prop::operator = (parent Window& w, int x)
{
// whatever custom code, then foward call to parent.
x_ = x;
w.paint();
}
void x_prop::operator += (parent Window& w, int x)
{
// whatever custom code, then foward call to parent.
x_ += x;
w.paint();
}
// window.h
#include "x_prop.h"
class Window
{
public:
x_prop x;
y_prop y;
void paint() { }
};
// main.cpp
int main()
{
Window w;
w.x = 10; // Move window absolute. w.x.operator=(w,10)
w.x += 10; // Move window relative.
cout << w.x; // w.x.operator()
}
// In the above example a reference to w is passed implicitly to operator =
of x after the "this" of x.
// instance x_prop stores no pointer itself to it's parent w.
Thoughts?
--
---
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_231_890791380.1420438997332
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><p>I haven't thought this through too much, but I was thin=
king..</p><p>Some objects are not meant to be used independent of their par=
ent object.<br>In such designs the sub object sometimes retains a pointer t=
o the parent object.<br>Often such a pointer is undesriable because of spac=
e efficiency or whatever.<br>But if one doesn't hold a back pointer, supply=
ing a parent object to a function on the sub object that needs it need=
s is tedious.</p><p>What if C++ had a feature to provide the parent of an e=
xpression implicitly to the subobect or something like that.</p><div>With o=
ther extensions, this idea or a variation on the theme might also enable a =
kind of "properties" proposal amongst other things so I'm using that as a c=
ontrived example of the feature.</div><div>I wonder if it might be useful t=
o the range proposal too in some way but I haven't considered that at all.<=
/div><div><br></div><p>// Contrived uncompilable example:</p><p>x_prop.h</p=
><p> #include "window.h"<br> class x_pr=
op<br> {<br> in=
t x_;<br> public:<br> =
x_prop() {}</p><p> void op=
erator =3D (parent Window& w, int x);<br> =
void operator +=3D (parent Window& w, int x);<br> &nb=
sp; int operator () { return _x; };<br> =
};</p><p>x_prop.cpp</p><p> void x_prop::oper=
ator =3D (parent Window& w, int x)<br> {<br> &nb=
sp; // whatever custom code, then foward call=
to parent.<br> x_ =3D x;<br>&nbs=
p; w.paint();<br> }<b=
r> void x_prop::operator +=3D (parent Window& w, int =
x)<br> {<br> //=
whatever custom code, then foward call to parent.<br> &nb=
sp; x_ +=3D x;<br> &nb=
sp; w.paint();<br> }</p><p><br>// window.h<br>#include "x=
_prop.h"</p><p>class Window<br>{<br>public:<br> x_prop x;=
<br> y_prop y;<br> void paint() { }<br>=
};</p><p><br>// main.cpp<br>int main()<br>{<br> Window w;=
<br> <br> w.x =3D 10; // Move window ab=
solute. w.x.operator=3D(w,10)<br> w.x +=3D 10; // Move wi=
ndow relative.<br> cout << w.x; // w.x.operator()<b=
r>}</p><p>// In the above example a reference to w is passed implicitly to =
operator =3D of x after the "this" of x.<br>// instance x_prop stores no po=
inter itself to it's parent w.</p><p><br>Thoughts?</p></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_231_890791380.1420438997332--
------=_Part_230_223272727.1420438997332--
.
Author: Brent Friedman <fourthgeek@gmail.com>
Date: Mon, 5 Jan 2015 02:31:45 -0600
Raw View
--001a113db21e544b46050be385a8
Content-Type: text/plain; charset=UTF-8
Why not have a function Window::x() which returns a temporary object with a
reference to the 'parent' and overloaded assignment operators? It's far
more flexible.
Counterexample:
Window w;
auto& x = w.x;
x = 5;
This code fragment can't work in your design because when we perform
assignment, no parent object was ever involved. This very much limits its
usefulness. If you instead had the implementation of x() returning a struct
then you could pass that struct around freely.
Furthermore, your solution only works if you want to go only 'one level
deep'. If, instead of x_prop and y_prop you had a point_prop containing an
x and y value then your syntax breaks down.
Window w;
w.pos.x += 4; //the 'parent' of x is pos, *not* w
Good architecture usually involves creating abstractions, but this parent
system destroys the ability to create useful abstractions beyond one level
deep.
Finally, there's a big implementation hurdle. I don't think you can simply
propagate the left side of the '. operator' all the way up to the +=
operator without a large grammatical revision to the language. To
implement, we would need Window::x to not be an int&, but instead be some
other sort of object that encapsulates the additional parameter. But at
this point we just have a restricted compiler-provided implementation of my
suggestion.
On Mon, Jan 5, 2015 at 12:23 AM, <gmisocpp@gmail.com> wrote:
> I haven't thought this through too much, but I was thinking..
>
> Some objects are not meant to be used independent of their parent object.
> In such designs the sub object sometimes retains a pointer to the parent
> object.
> Often such a pointer is undesriable because of space efficiency or
> whatever.
> But if one doesn't hold a back pointer, supplying a parent object to a
> function on the sub object that needs it needs is tedious.
>
> What if C++ had a feature to provide the parent of an expression
> implicitly to the subobect or something like that.
> With other extensions, this idea or a variation on the theme might also
> enable a kind of "properties" proposal amongst other things so I'm using
> that as a contrived example of the feature.
> I wonder if it might be useful to the range proposal too in some way but I
> haven't considered that at all.
>
> // Contrived uncompilable example:
>
> x_prop.h
>
> #include "window.h"
> class x_prop
> {
> int x_;
> public:
> x_prop() {}
>
> void operator = (parent Window& w, int x);
> void operator += (parent Window& w, int x);
> int operator () { return _x; };
> };
>
> x_prop.cpp
>
> void x_prop::operator = (parent Window& w, int x)
> {
> // whatever custom code, then foward call to parent.
> x_ = x;
> w.paint();
> }
> void x_prop::operator += (parent Window& w, int x)
> {
> // whatever custom code, then foward call to parent.
> x_ += x;
> w.paint();
> }
>
>
> // window.h
> #include "x_prop.h"
>
> class Window
> {
> public:
> x_prop x;
> y_prop y;
> void paint() { }
> };
>
>
> // main.cpp
> int main()
> {
> Window w;
>
> w.x = 10; // Move window absolute. w.x.operator=(w,10)
> w.x += 10; // Move window relative.
> cout << w.x; // w.x.operator()
> }
>
> // In the above example a reference to w is passed implicitly to operator
> = of x after the "this" of x.
> // instance x_prop stores no pointer itself to it's parent w.
>
>
> Thoughts?
>
> --
>
> ---
> 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/.
>
--
---
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/.
--001a113db21e544b46050be385a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Why not have a function Window::x() which returns a t=
emporary object with a reference to the 'parent' and overloaded ass=
ignment operators? It's far more flexible.<br></div><div><br></div><div=
>Counterexample:</div><div>Window w;<br></div><div>auto& x =3D w.x;</di=
v><div>x =3D 5;</div><div><br></div><div>This code fragment can't work =
in your design because when we perform assignment, no parent object was eve=
r involved. This very much limits its usefulness. If you instead had the im=
plementation of x() returning a struct then you could pass that struct arou=
nd freely.</div><div><br></div><div>Furthermore, your solution only works i=
f you want to go only 'one level deep'. If, instead of x_prop and y=
_prop you had a point_prop containing an x and y value then your syntax bre=
aks down.</div><div><br></div><div>Window w;</div><div>w.pos.x +=3D 4; //th=
e 'parent' of x is pos, *not* w</div><div><br></div><div>Good archi=
tecture usually involves creating abstractions, but this parent system dest=
roys the ability to create useful abstractions beyond one level deep.</div>=
<div><br></div><div>Finally, there's a big implementation hurdle. I don=
't think you can simply propagate the left side of the '. operator&=
#39; all the way up to the +=3D operator without a large grammatical revisi=
on to the language. To implement, we would need Window::x to not be an int&=
amp;, but instead be some other sort of object that encapsulates the additi=
onal parameter. But at this point we just have a restricted compiler-provid=
ed implementation of my suggestion.</div></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Mon, Jan 5, 2015 at 12:23 AM, <span dir=
=3D"ltr"><<a href=3D"mailto:gmisocpp@gmail.com" target=3D"_blank">gmisoc=
pp@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><p>I haven't thought this through too much, but I was thinki=
ng..</p><p>Some objects are not meant to be used independent of their paren=
t object.<br>In such designs the sub object sometimes retains a pointer to =
the parent object.<br>Often such a pointer is undesriable because of space =
efficiency or whatever.<br>But if one doesn't hold a back pointer, supp=
lying a parent object to a function on the sub object that needs=C2=A0it ne=
eds is tedious.</p><p>What if C++ had a feature to provide the parent of an=
expression implicitly to the subobect or something like that.</p><div>With=
other extensions, this idea or a variation on the theme might also enable =
a kind of "properties" proposal amongst other things so I'm u=
sing that as a contrived example of the feature.</div><div>I wonder if it m=
ight be useful to the range proposal too in some way but I haven't cons=
idered that at all.</div><div><br></div><p>// Contrived uncompilable exampl=
e:</p><p>x_prop.h</p><p>=C2=A0=C2=A0=C2=A0 #include "window.h"<br=
>=C2=A0=C2=A0=C2=A0 class x_prop<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 int x_;<br>=C2=A0=C2=A0=C2=A0 public:<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x_prop() {}</p><p>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 void operator =3D (parent Window& w, int x);<b=
r>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void operator +=3D (parent Win=
dow& w, int x);<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int opera=
tor () { return _x; };<br>=C2=A0=C2=A0=C2=A0 };</p><p>x_prop.cpp</p><p>=C2=
=A0=C2=A0=C2=A0 void x_prop::operator =3D (parent Window& w, int x)<br>=
=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // whate=
ver custom code, then foward call to parent.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 x_ =3D x;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 w.p=
aint();<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 void x_prop::operator=
+=3D (parent Window& w, int x)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // whatever custom code, then foward call to=
parent.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x_ +=3D x;<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 w.paint();<br>=C2=A0=C2=A0=C2=A0 }</p>=
<p><br>// window.h<br>#include "x_prop.h"</p><p>class Window<br>{=
<br>public:<br>=C2=A0=C2=A0=C2=A0 x_prop x;<br>=C2=A0=C2=A0=C2=A0 y_prop y;=
<br>=C2=A0=C2=A0=C2=A0 void paint() { }<br>};</p><p><br>// main.cpp<br>int =
main()<br>{<br>=C2=A0=C2=A0=C2=A0 Window w;<br>=C2=A0=C2=A0=C2=A0 <br>=C2=
=A0=C2=A0=C2=A0 w.x =3D 10; // Move window absolute. w.x.operator=3D(w,10)<=
br>=C2=A0=C2=A0=C2=A0 w.x +=3D 10; // Move window relative.<br>=C2=A0=C2=A0=
=C2=A0 cout << w.x; // w.x.operator()<br>}</p><p>// In the above exam=
ple a reference to w is passed implicitly to operator =3D of x after the &q=
uot;this" of x.<br>// instance x_prop stores no pointer itself to it&#=
39;s parent w.</p><p><br>Thoughts?</p></div><span class=3D"HOEnZb"><font co=
lor=3D"#888888">
<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><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 />
--001a113db21e544b46050be385a8--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 5 Jan 2015 17:31:45 +0800
Raw View
--Apple-Mail=_DC3D98CB-5543-4663-B68C-89189AF73094
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9301=E2=80=9305, at 2:23 PM, gmisocpp@gmail.com wrote:
>=20
> Some objects are not meant to be used independent of their parent object.
> In such designs the sub object sometimes retains a pointer to the parent =
object.
> Often such a pointer is undesriable because of space efficiency or whatev=
er.
> But if one doesn't hold a back pointer, supplying a parent object to a fu=
nction on the sub object that needs it needs is tedious.
>=20
This will be handled by member expression aliases, which are likely coming =
soon in some form or another.
--=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/.
--Apple-Mail=_DC3D98CB-5543-4663-B68C-89189AF73094
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9305, at 2:23 PM, <a href=3D"mailto:gmisocpp@gmail.com" class=3D"">g=
misocpp@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><=
div class=3D""><p style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px;" class=3D"">Some objects are not meant =
to be used independent of their parent object.<br class=3D"">In such design=
s the sub object sometimes retains a pointer to the parent object.<br class=
=3D"">Often such a pointer is undesriable because of space efficiency or wh=
atever.<br class=3D"">But if one doesn't hold a back pointer, supplying a p=
arent object to a function on the sub object that needs it needs is te=
dious.</p></div></blockquote></div><br class=3D""><div class=3D"">This will=
be handled by member expression aliases, which are likely coming soon in s=
ome form or another.</div></body></html>
<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 />
--Apple-Mail=_DC3D98CB-5543-4663-B68C-89189AF73094--
.
Author: gmisocpp@gmail.com
Date: Mon, 5 Jan 2015 02:13:25 -0800 (PST)
Raw View
------=_Part_7682_1628446084.1420452805421
Content-Type: multipart/alternative;
boundary="----=_Part_7683_2146969751.1420452805426"
------=_Part_7683_2146969751.1420452805426
Content-Type: text/plain; charset=UTF-8
On Monday, January 5, 2015 9:31:47 PM UTC+13, Brent Friedman wrote:
>
> Why not have a function Window::x() which returns a temporary object with
> a reference to the 'parent' and overloaded assignment operators? It's far
> more flexible.
>
I'm not sure I understand what you mean but it sounds like it requires
someone to store a pointer to a temporary which is what I'm trying to avoid.
>
> Counterexample:
> Window w;
> auto& x = w.x;
> x = 5;
>
> This code fragment can't work in your design because when we perform
> assignment, no parent object was ever involved. This very much limits its
> usefulness. If you instead had the implementation of x() returning a struct
> then you could pass that struct around freely.
>
I'm ok for your fragment not to work. My proposal should work for simple
properties. For more complex, using your method is ok.
> Furthermore, your solution only works if you want to go only 'one level
> deep'. If, instead of x_prop and y_prop you had a point_prop containing an
> x and y value then your syntax breaks down.
>
Yes that's true. But don't use it for that case. Use your method.
>
> Window w;
> w.pos.x += 4; //the 'parent' of x is pos, *not* w
>
>
> Good architecture usually involves creating abstractions, but this parent
> system destroys the ability to create useful abstractions beyond one level
> deep.
>
It doesn't destroy anything. It doesn't take any facility away. You can
still use whatever you already use where that works better.
>
> Finally, there's a big implementation hurdle. I don't think you can simply
> propagate the left side of the '. operator' all the way up to the +=
> operator without a large grammatical revision to the language. To
> implement, we would need Window::x to not be an int&, but instead be some
> other sort of object that encapsulates the additional parameter. But at
> this point we just have a restricted compiler-provided implementation of my
> suggestion.
>
Yes it requires change to the language. I can't say if it's 'big' or not
but it's not if it's big that matters, it's if it's worth it that matters.
Others more equipped than me have to decide if it's a change that's worth
it or not and that depends on the value of it which will increase or
decrease as people see a use for the idea or not. I'm putting the rough
idea out there to see what people make of it and to see if how people think
it can be built upon or not. Most ideas come to nothing or have already
been proposed but that's ok.
Thanks for your thoughts. :)
--
---
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_7683_2146969751.1420452805426
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, January 5, 2015 9:31:47 PM UTC+13, Bren=
t Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Why not=
have a function Window::x() which returns a temporary object with a refere=
nce to the 'parent' and overloaded assignment operators? It's far more flex=
ible.<br></div></div></blockquote><div><br></div><div>I'm not sure I unders=
tand what you mean but it sounds like it requires someone to store a p=
ointer to a temporary which is what I'm trying to avoid.</div><div> </=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
1px; border-left-style: solid;"><div dir=3D"ltr"><div></div><div><br></div=
><div>Counterexample:</div><div>Window w;<br></div><div>auto& x =3D w.x=
;</div><div>x =3D 5;</div><div><br></div><div>This code fragment can't work=
in your design because when we perform assignment, no parent object was ev=
er involved. This very much limits its usefulness. If you instead had the i=
mplementation of x() returning a struct then you could pass that struct aro=
und freely.</div></div></blockquote><div> </div><div>I'm ok for y=
our fragment not to work. My proposal should work for simple prop=
erties. For more complex, using your method is ok.</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;"><div dir=3D"ltr"><div><br></div><div>Furthermore, =
your solution only works if you want to go only 'one level deep'. If, inste=
ad of x_prop and y_prop you had a point_prop containing an x and y value th=
en your syntax breaks down.</div></div></blockquote><div><br></div><div>Yes=
that's true. But don't use it for that case. Use your method.</d=
iv><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br>=
</div><div>Window w;</div><div>w.pos.x +=3D 4; //the 'parent' of x is pos, =
*not* w</div></div></blockquote><div> </div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-=
color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid=
;"><div dir=3D"ltr"><div><br></div><div>Good architecture usually involves =
creating abstractions, but this parent system destroys the ability to creat=
e useful abstractions beyond one level deep.</div></div></blockquote><div><=
br></div><div>It doesn't destroy anything. It doesn't take any facility awa=
y. You can still use whatever you already use where that wor=
ks better.</div><div> </div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, =
204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"l=
tr"><div><br></div><div>Finally, there's a big implementation hurdle. I don=
't think you can simply propagate the left side of the '. operator' all the=
way up to the +=3D operator without a large grammatical revision to the la=
nguage. To implement, we would need Window::x to not be an int&, but in=
stead be some other sort of object that encapsulates the additional paramet=
er. But at this point we just have a restricted compiler-provided implement=
ation of my suggestion.</div></div></blockquote><div><br></div><div>Yes it =
requires change to the language. I can't say if it's 'big' o=
r not but it's not if it's big that matters, it's if it's worth it tha=
t matters.</div><div><br></div><div>Others more equipped than me =
have to decide if it's a change that's worth it or not =
and that depends on the value of it which will increase or d=
ecrease as people see a use for the idea or not. I'm putting the=
rough idea out there to see what people make of it and to see if =
;how people think it can be built upon or not. Most ideas come to nothing o=
r have already been proposed but that's ok.</div><div><br></div><div>T=
hanks for your thoughts. :)</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_7683_2146969751.1420452805426--
------=_Part_7682_1628446084.1420452805421--
.
Author: gmisocpp@gmail.com
Date: Mon, 5 Jan 2015 02:14:28 -0800 (PST)
Raw View
------=_Part_8_32461554.1420452868686
Content-Type: multipart/alternative;
boundary="----=_Part_9_120491740.1420452868687"
------=_Part_9_120491740.1420452868687
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, January 5, 2015 10:31:55 PM UTC+13, David Krauss wrote:
>
>
> On 2015=E2=80=9301=E2=80=9305, at 2:23 PM, gmis...@gmail.com <javascript:=
> wrote:
>
> Some objects are not meant to be used independent of their parent object.
> In such designs the sub object sometimes retains a pointer to the parent=
=20
> object.
> Often such a pointer is undesriable because of space efficiency or=20
> whatever.
> But if one doesn't hold a back pointer, supplying a parent object to a=20
> function on the sub object that needs it needs is tedious.
>
>
> This will be handled by member expression aliases, which are likely comin=
g=20
> soon in some form or another.
>
What's a member expression alias and what is an example form of that?=20
--=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_9_120491740.1420452868687
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, January 5, 2015 10:31:55 PM UTC+13, Dav=
id Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wrap: b=
reak-word;"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9301=E2=
=80=9305, at 2:23 PM, <a onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"Q7l0kJ4ijfIJ">gmis...@gmail.co=
m</a> wrote:</div><br><div><p style=3D"font: 12px/normal Helvetica; text-tr=
ansform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px;=
white-space: normal; font-size-adjust: none; font-stretch: normal;">Some o=
bjects are not meant to be used independent of their parent object.<br>In s=
uch designs the sub object sometimes retains a pointer to the parent object=
..<br>Often such a pointer is undesriable because of space efficiency or wha=
tever.<br>But if one doesn't hold a back pointer, supplying a parent object=
to a function on the sub object that needs it needs is tedious.</p></=
div></blockquote></div><br><div>This will be handled by member expression a=
liases, which are likely coming soon in some form or another.</div></div></=
blockquote><div><br></div><div>What's a member expression alias and what is=
an example form of that? </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_9_120491740.1420452868687--
------=_Part_8_32461554.1420452868686--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 5 Jan 2015 19:03:45 +0800
Raw View
--Apple-Mail=_1F29F2C1-DF37-4082-8EE5-C3D8F4B16384
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9301=E2=80=9305, at 6:14 PM, gmisocpp@gmail.com wrote:
>=20
>=20
>=20
> On Monday, January 5, 2015 10:31:55 PM UTC+13, David Krauss wrote:
>=20
> This will be handled by member expression aliases, which are likely comin=
g soon in some form or another.
>=20
> What's a member expression alias and what is an example form of that?=20
An expression alias is essentially like an inline function that doesn=E2=80=
=99t need parentheses to be called. When defined as a member, it has access=
to this.
There are some examples in my proposal N4147, see =C2=A72.5 and 2.6. The pr=
oposal was rejected, but the committee did express interest in having such =
a feature. (I completely misjudged what part of it would be controversial. =
I thought they wouldn=E2=80=99t want to allow properties, but the complaint=
s were about having linkage [which doesn=E2=80=99t make sense; linkage ulti=
mately needs to be specified for everything], and that the syntax looks too=
much like a variable.)
Richard Smith has expressed similar ideas, and we agree on the principles o=
f what this should do in such a context, i.e. an =E2=80=9Cimplicit parent r=
eference.=E2=80=9D Look for a paper from him, perhaps soon. It=E2=80=99s po=
ssible but unlikely that I=E2=80=99ll do more work on this subject before t=
hat happens. (Considering the debate on my proposal, it=E2=80=99s possible =
that the committee is simply reluctant to endorse something else before eva=
luating the feature which Richard has already prototyped. But that is also =
evidence of momentum towards solving your problem.)
--=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/.
--Apple-Mail=_1F29F2C1-DF37-4082-8EE5-C3D8F4B16384
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9305, at 6:14 PM, <a href=3D"mailto:gmisocpp@gmail.com" class=3D"">g=
misocpp@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><=
div class=3D""><div dir=3D"ltr" class=3D""><br class=3D""><br class=3D"">On=
Monday, January 5, 2015 10:31:55 PM UTC+13, David Krauss wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div style=3D"-ms-word-wrap: break-word;" class=3D""><br =
class=3D""><div class=3D"">This will be handled by member expression aliase=
s, which are likely coming soon in some form or another.</div></div></block=
quote><div class=3D""><br class=3D""></div><div class=3D"">What's a member =
expression alias and what is an example form of that? </div></div></di=
v></blockquote><br class=3D""></div><div>An expression alias is essentially=
like an inline function that doesn=E2=80=99t need parentheses to be called=
.. When defined as a member, it has access to <font face=3D"Courier" class=
=3D"">this</font>.</div><div><br class=3D""></div><div>There are some examp=
les in my proposal N4147, see =C2=A72.5 and 2.6. The proposal was rejected,=
but the committee did express interest in having such a feature. (I comple=
tely misjudged what part of it would be controversial. I thought they would=
n=E2=80=99t want to allow properties, but the complaints were about having =
linkage [which doesn=E2=80=99t make sense; linkage ultimately needs to be s=
pecified for everything], and that the syntax looks too much like a variabl=
e.)</div><div><br class=3D""></div><div>Richard Smith has expressed similar=
ideas, and we agree on the principles of what <font face=3D"Courier" class=
=3D"">this</font> should do in such a context, i.e. an =E2=80=9Cimplicit pa=
rent reference.=E2=80=9D Look for a paper from him, perhaps soon. It=E2=80=
=99s possible but unlikely that I=E2=80=99ll do more work on this subject b=
efore that happens. (Considering the debate on my proposal, it=E2=80=99s po=
ssible that the committee is simply reluctant to endorse something else bef=
ore evaluating the feature which Richard has already prototyped. But that i=
s also evidence of momentum towards solving your problem.)</div></body></ht=
ml>
<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 />
--Apple-Mail=_1F29F2C1-DF37-4082-8EE5-C3D8F4B16384--
.
Author: gmisocpp@gmail.com
Date: Mon, 5 Jan 2015 05:32:38 -0800 (PST)
Raw View
------=_Part_613_1348424613.1420464758925
Content-Type: multipart/alternative;
boundary="----=_Part_614_577543900.1420464758926"
------=_Part_614_577543900.1420464758926
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, January 6, 2015 12:04:02 AM UTC+13, David Krauss wrote:
>
>
> On 2015=E2=80=9301=E2=80=9305, at 6:14 PM, gmis...@gmail.com <javascript:=
> wrote:
>
>
>
> On Monday, January 5, 2015 10:31:55 PM UTC+13, David Krauss wrote:
>>
>>
>> This will be handled by member expression aliases, which are likely=20
>> coming soon in some form or another.
>>
>
> What's a member expression alias and what is an example form of that?=20
>
>
> An expression alias is essentially like an inline function that doesn=E2=
=80=99t=20
> need parentheses to be called. When defined as a member, it has access to=
=20
> this.
>
> There are some examples in my proposal N4147, see =C2=A72.5 and 2.6. The=
=20
> proposal was rejected, but the committee did express interest in having=
=20
> such a feature. (I completely misjudged what part of it would be=20
> controversial. I thought they wouldn=E2=80=99t want to allow properties, =
but the=20
> complaints were about having linkage [which doesn=E2=80=99t make sense; l=
inkage=20
> ultimately needs to be specified for everything], and that the syntax loo=
ks=20
> too much like a variable.)
>
> Richard Smith has expressed similar ideas, and we agree on the principles=
=20
> of what this should do in such a context, i.e. an =E2=80=9Cimplicit paren=
t=20
> reference.=E2=80=9D Look for a paper from him, perhaps soon. It=E2=80=99s=
possible but=20
> unlikely that I=E2=80=99ll do more work on this subject before that happe=
ns.=20
> (Considering the debate on my proposal, it=E2=80=99s possible that the co=
mmittee is=20
> simply reluctant to endorse something else before evaluating the feature=
=20
> which Richard has already prototyped. But that is also evidence of moment=
um=20
> towards solving your problem.)
>
Thanks for the update. I'm keen to see what Richard is thinking about. I'm=
=20
overall pretty excited about the interesting things being worked on by=20
various people and how they look like they might come together pretty=20
nicely.
--=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_614_577543900.1420464758926
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, January 6, 2015 12:04:02 AM UTC+13, Da=
vid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wrap: =
break-word;"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9301=E2=
=80=9305, at 6:14 PM, <a onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"oyQkEzl8SLQJ">gmis...@gmail.co=
m</a> wrote:</div><br><div><div dir=3D"ltr"><br><br>On Monday, January 5, 2=
015 10:31:55 PM UTC+13, David Krauss wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><di=
v><br><div>This will be handled by member expression aliases, which are lik=
ely coming soon in some form or another.</div></div></blockquote><div><br><=
/div><div>What's a member expression alias and what is an example form of t=
hat? </div></div></div></blockquote><br></div><div>An expression alias=
is essentially like an inline function that doesn=E2=80=99t need parenthes=
es to be called. When defined as a member, it has access to <font face=3D"C=
ourier">this</font>.</div><div><br></div><div>There are some examples in my=
proposal N4147, see =C2=A72.5 and 2.6. The proposal was rejected, but the =
committee did express interest in having such a feature. (I completely misj=
udged what part of it would be controversial. I thought they wouldn=E2=80=
=99t want to allow properties, but the complaints were about having linkage=
[which doesn=E2=80=99t make sense; linkage ultimately needs to be specifie=
d for everything], and that the syntax looks too much like a variable.)</di=
v><div><br></div><div>Richard Smith has expressed similar ideas, and we agr=
ee on the principles of what <font face=3D"Courier">this</font> should do i=
n such a context, i.e. an =E2=80=9Cimplicit parent reference.=E2=80=9D Look=
for a paper from him, perhaps soon. It=E2=80=99s possible but unlikely tha=
t I=E2=80=99ll do more work on this subject before that happens. (Consideri=
ng the debate on my proposal, it=E2=80=99s possible that the committee is s=
imply reluctant to endorse something else before evaluating the feature whi=
ch Richard has already prototyped. But that is also evidence of momentum to=
wards solving your problem.)</div></div></blockquote><div><br></div><div>Th=
anks for the update. I'm keen to see what Richard is thinking about. I=
'm overall pretty excited about the interesting things being worked on by v=
arious people and how they look like they might come together&nbs=
p;pretty nicely.</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_614_577543900.1420464758926--
------=_Part_613_1348424613.1420464758925--
.