220 16990 article Path: news.gmane.org!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Token based access to private members in reflection Date: Fri, 13 Mar 2015 15:09:18 -0700 (PDT) Lines: 356 Approved: news@gmane.org Message-ID: References: <104b02bf-a3bc-495a-870e-9af9e1ec1fdf@isocpp.org> <04b687bc-2cf5-402f-bb27-0365f77169b5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1014_1779994983.1426284558420" X-Trace: ger.gmane.org 1426284570 2868 80.91.229.3 (13 Mar 2015 22:09:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Mar 2015 22:09:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDLTAGNTIBBBD6ARWUAKGQE4KUDZDQ@isocpp.org Fri Mar 13 23:09:22 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YWXlg-0006Pp-O3 for gclcip-std-proposals@m.gmane.org; Fri, 13 Mar 2015 23:09:21 +0100 Original-Received: by ieqm10 with SMTP id m10sf63206577ieq.1 for ; Fri, 13 Mar 2015 15:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=nBVpUhPQwChchJ9JUpZnTFOXSr2Gruqhzm5NvzkISWY=; b=o6eCf4sIFyQCV1oMxvYKAUc9SIfWAU5C4agLkknfFcqDxFCGZ80Dj6xR5wHuh4icu6 5qV2HYfrvvUnLXH33SRpLrqWZ/nTc/0n7FzyJAil/+oZPynUGluWPozM8HJOSVbcKsEb pj/MwfpajUvob1k+XS5DP0TAkTQ182Ls0JoLPtc5IDvm6KztKfxjlPPAd+gCjeOd1IOt FZIXqLrCHbwb2zqQLA/Mzow5Y4jHMtUbSDFoE/5cEeKYzfquz9xDTkd8iC6ZHFgvvJQl tbkA2aEA0xsZyUTWQ25X+ERkzR0KeBHsz8lXhV4pIHqfk2Z0pzjM0TIhsgC6W4D+tb38 JrCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=nBVpUhPQwChchJ9JUpZnTFOXSr2Gruqhzm5NvzkISWY=; b=V4BFbtnrxfea2CJgMkHY5D1ct3vxT2tIvZ845yET5Z77T8UgEx2RXdu6KhtKe8PPhj tRiUKdT/4Y/fLdFxP1EGrcvBPWGtl0b0DW3wSeQ5bJ2Txp6jCJnPK5eNg9hDUwa9e/hl Fih1pNSa+Ar9v4HhjTNTegtj9lU8ZzpHkN/oNoXs1gPrzoKr6aW4b9+dkFsk70SuZUIl PDgLo+lNbX+AJJnBfX77SqHghiKGVfenri9IxcLZjTeXfu0Vk+HqPa8datz9hUpZ6KBn ztTRC4pH8slVSswYJaFWf1f5F7qo3QGIgTtvDWY4fesVfhiCXeguH95e0sWWzxz8OtoI ZWuQ== X-Gm-Message-State: ALoCoQkZyzYysVkFFNBJRwZ2CpuCRU17yl1K+ygaHqvtpjBss8/VsJfjlTyTZKTk/IYi3Nc+CXGW X-Received: by 10.50.122.7 with SMTP id lo7mr18134663igb.7.1426284559850; Fri, 13 Mar 2015 15:09:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.98.72 with SMTP id n66ls1977233qge.71.gmail; Fri, 13 Mar 2015 15:09:19 -0700 (PDT) X-Received: by 10.140.92.55 with SMTP id a52mr771365qge.16.1426284559140; Fri, 13 Mar 2015 15:09:19 -0700 (PDT) In-Reply-To: X-Original-Sender: inkwizytoryankes@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:16990 Archived-At: ------=_Part_1014_1779994983.1426284558420 Content-Type: multipart/alternative; boundary="----=_Part_1015_1928476571.1426284558420" ------=_Part_1015_1928476571.1426284558420 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I see, this is unfixable problem. Only way I see my example could fulfill= =20 this requirement is add special token that is named `hack_this_please` with= =20 oblivious functionality. This at least would separate legit use of private members (like=20 serialization) and hack that are workaround of class limitations (like lack= =20 of support for serialization :) ). But this is in itself hack of my proposition. On Friday, March 13, 2015 at 10:44:09 PM UTC+1, Ville Voutilainen wrote: > > > > On 13 March 2015 at 23:25, > wrote: > >> Do you know why people was against this approach? >> > > There is a desire to use reflection on legacy types that would be=20 > infeasible > to modify to contain such a token. > =20 > >> >> >> On Friday, March 13, 2015 at 12:22:15 AM UTC+1, Cleiton Santoia wrote: >>> >>> >>> >>> >>> In this document http://random.m-ou.se/reflectionfeedbackurbana.htm= l you=20 >>> will find : >>> >>> >>> Opt-in to unsafe reflection from the class under reflection: >>> SFFNASA543102 >>> >>> >>> >>> Em quinta-feira, 12 de mar=C3=A7o de 2015 19:46:29 UTC-3,=20 >>> inkwizyt...@gmail.com escreveu: >>>> >>>> I have idea of system that could be used of handling private data in= =20 >>>> reflection. >>>> >>>> First one, we add new template >>>> template >>>> class private_access_token >>>> { >>>> using type =3D /* undefined */; >>>> friend T; >>>> }; >>>> >>>> >>>> And we add to `class_member::pointer` (like from n4113) new default=20 >>>> parameter: >>>> template >>>> struct pointer >>>> { >>>> private: //this line depend if I'th member is private >>>> constexpr static SomeType T::* value =3D /* something */; >>>> friend T; >>>> }; >>>> >>>> template >>>> struct pointer::type > >>>> { >>>> public: //always public with token >>>> constexpr static SomeType T::* value =3D /* something */; >>>> friend T; >>>> }; >>>> >>>> >>>> >>>> >>>> Thanks to that, class implementation can have control over private=20 >>>> access and allow sharing it to third party libraries without exposing= =20 >>>> private fields to the wild. >>>> Some class designer could even allow every one using it by exposing=20 >>>> type form token: >>>> class A >>>> { >>>> int a; >>>> public: >>>> using PrivateToken =3D private_access_token::type; >>>> }; >>>> >>>> class B >>>> { >>>> int a; >>>> int b; >>>> public: >>>> std::string to_string() { return third_party_func>>> access_token::type>(this); } >>>> }; >>>> >>>> >>>> >>>> Do you think that could be good solution for that? >>>> >>>> >>>> --=20 >> >> ---=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to std-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> Visit this group at=20 >> http://groups.google.com/a/isocpp.org/group/std-proposals/. >> > > --=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_1015_1928476571.1426284558420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see, this is unfixable problem. Only way I see my exampl= e could fulfill this requirement is add special token that is named `hack_t= his_please` with oblivious functionality.
This at least would separate l= egit use of private members (like serialization) and hack that are workarou= nd of class limitations (like lack of support for serialization :) ).
Bu= t this is in itself hack of my proposition.

On Friday, March 13, 201= 5 at 10:44:09 PM UTC+1, Ville Voutilainen wrote:


= On 13 March 2015 at 23:25, <inkwizyt...@gmail.com> wrote:<= br>
Do you know why people w= as against this approach?

There is a = desire to use reflection on legacy types that would be infeasible
=
to modify to contain such a token.
 


On Friday, March 13, 2015= at 12:22:15 AM UTC+1, Cleiton Santoia wrote:




Em quinta-feira, 12 de mar=C3=A7o de 2015 19:46:29 UTC-3, inkwizy= t...@gmail.com escreveu:
I have idea of system that could be used of handling private dat= a in reflection.

First one, we add new template
template<typename T>
class private_access_tok= en
{=
    using type =3D /* undefined */= ;
  &n= bsp; friend T;=
};<= br>


And we add to `class_member::pointer` = (like from n4113) new default parameter:
templat= e<ty= pename T, size_t I, token =3D void>
struct pointer
{
private: //this line depend if I'th member is private
    constex= pr stat= ic Some= Type T:= :* value =3D /= * something */;
    friend T;
};

template<typename= T, size_t I&g= t;
s= truct pointer<T, I= , typen= ame private_access_token<T>::type >
{
public: //always public with = token
    constexpr static SomeType T::* value =3D /* something */;
    friend T;
};




Thanks to that, class implementation can have control over pr= ivate access and allow sharing it to third party libraries without exposing= private fields to the wild.
Some class designer could even allow every = one using it by exposing type form token:
class<= /span> A
{<= /span>
    int a;
public:
    using PrivateToken =3D private_access_token<A>::type;
};

class B
{
    int a;
    <= /span>int b;
public:
    std::string to_string() { return third_party_func<private_access_token<B>::type>(this); }
};



Do you think that could be good solution 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 e= mail to std-proposal.= ...@isocpp.org.
To post to this group, send email to std-pr...@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 &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_1015_1928476571.1426284558420-- ------=_Part_1014_1779994983.1426284558420-- .