Date: Tue, 12 Nov 2024 21:48:27 +0200
On Tue, 12 Nov 2024 at 21:31, Herb Sutter <herb.sutter_at_[hidden]> wrote:
> That is why I'm still open to examples, but so far I'm convinced that
> metadata != data, and we routinely need to *reflect* on all *metadata* (and
> can then filter exactly what we want no problem) even as I agree that we
> also want to be able to avoid *generating* code that bypasses *data*
> accessibility by default.
>
> Adding a rule only for reflecting accessible data seems like targeting only
> one use case, and doing it at the wrong level (reading metadata, not
> accessing data).
It targets multiple use cases: memberwise operation injection, wrapper
generation, boilerplate generation.
Even in an injected memberwise friend, get_accessible_members is the
right question to ask, because
when programming like the language works, you have access to the data
and metadata of the befriended
class, but not to data or metadata or anything else.
In other words, if you look at the UserBar example in the paper, its
memberwise_hash() member uses
get_accessible_members(), instead of an operation that would give
metadata access to something you
don't have data access to. And based on that, I know that it's not
grabbing data nor metadata of anything
that the language wouldn't allow it to. It grabs the metadata and data
of UserBar, but not either metadata or data
of the type of any of UserBar::what, UserBar::data, UserBar::to,
UserBar::goes. I know that just by looking
at what sort of a reflection query it performs, I know that just by
finding a get_accessible_members there,
instead of finding, say, members_of.
Likewise, in, say, fiddle(X&), if I use get_accessible_members(), I
know that it doesn't grab the private metadata
of the type of X::c1, i.e. C1. fiddle(X&) has access to X::c1, but it
doesn't have access to the privates of C1.
And when I use get_accessible_members() in fiddle(X&), I categorically
know that it won't be messing
with the privates of C1, even private metadata, or the metadata of privates.
This is nothing like querying only nonvirtual functions, or only
non-customized assignent operators.
get_accessible_members() is the basis operation on top of which I
build my other uses.
Yes, there are uses where you need to do more intrusive access. But
there's loads of use cases that do not need
that, and for those, get_accessible_members() is the correct building
block because it gives you the members the language
would, by obeying the language's access rules, even for metadata.
> That is why I'm still open to examples, but so far I'm convinced that
> metadata != data, and we routinely need to *reflect* on all *metadata* (and
> can then filter exactly what we want no problem) even as I agree that we
> also want to be able to avoid *generating* code that bypasses *data*
> accessibility by default.
>
> Adding a rule only for reflecting accessible data seems like targeting only
> one use case, and doing it at the wrong level (reading metadata, not
> accessing data).
It targets multiple use cases: memberwise operation injection, wrapper
generation, boilerplate generation.
Even in an injected memberwise friend, get_accessible_members is the
right question to ask, because
when programming like the language works, you have access to the data
and metadata of the befriended
class, but not to data or metadata or anything else.
In other words, if you look at the UserBar example in the paper, its
memberwise_hash() member uses
get_accessible_members(), instead of an operation that would give
metadata access to something you
don't have data access to. And based on that, I know that it's not
grabbing data nor metadata of anything
that the language wouldn't allow it to. It grabs the metadata and data
of UserBar, but not either metadata or data
of the type of any of UserBar::what, UserBar::data, UserBar::to,
UserBar::goes. I know that just by looking
at what sort of a reflection query it performs, I know that just by
finding a get_accessible_members there,
instead of finding, say, members_of.
Likewise, in, say, fiddle(X&), if I use get_accessible_members(), I
know that it doesn't grab the private metadata
of the type of X::c1, i.e. C1. fiddle(X&) has access to X::c1, but it
doesn't have access to the privates of C1.
And when I use get_accessible_members() in fiddle(X&), I categorically
know that it won't be messing
with the privates of C1, even private metadata, or the metadata of privates.
This is nothing like querying only nonvirtual functions, or only
non-customized assignent operators.
get_accessible_members() is the basis operation on top of which I
build my other uses.
Yes, there are uses where you need to do more intrusive access. But
there's loads of use cases that do not need
that, and for those, get_accessible_members() is the correct building
block because it gives you the members the language
would, by obeying the language's access rules, even for metadata.
Received on 2024-11-12 19:48:40