220 24990 <56DC58FC.9020009@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: "Components" template with implicitly defined partial specializations for all classes Date: Sun, 6 Mar 2016 17:21:16 +0100 Lines: 294 Approved: news@gmane.org Message-ID: <56DC58FC.9020009@wanadoo.fr> References: <56D9E17F.2070202@wanadoo.fr> <2b0bcca0-0939-49f7-939b-4d688f8dfe34@isocpp.org> <324dbff9-84da-46f2-b2f3-3d9fe0cc2082@isocpp.org> <56DA88DF.90000@wanadoo.fr> <7e46c46d-2e18-4cec-92c1-4f4d7fbc786b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070604040300020203050503" X-Trace: ger.gmane.org 1457281290 477 80.91.229.3 (6 Mar 2016 16:21:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Mar 2016 16:21:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBB7NR6G3AKGQEU6TPBDA@isocpp.org Sun Mar 06 17:21:21 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f198.google.com ([209.85.217.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1acbQl-0005J2-Md for gclcip-std-proposals@m.gmane.org; Sun, 06 Mar 2016 17:21:19 +0100 Original-Received: by mail-lb0-f198.google.com with SMTP id kl15sf41858218lbb.3 for ; Sun, 06 Mar 2016 08:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=QUqeZuaS8XNJ9MjZpOyhbx1cr9GgmiTX6b2QLoNBsZg=; b=WvLi7KVRoaB/R28OK2kp9oxWb8ysZwMFeaHOjIt3hWRJCaOqgPWYl+QsxMVMZbKuWu UYVwupUQW1WB7TPBX0ob5B6GGFQG4MXM9y7ml8uDbAkatojJZIwarLjaUyrkyNKMdAF1 97phI3xaJF3O1xNR9f27hyC54u0n/thjn43iwOKx7udJfAPmf36DxcNfAgOslkUlBaEo GeZ/6X8QMHd8U5Ma3CdSsRrUxnmv1O0Hg2l4G6VjGqIM/ojE3wwX83jZI+8XQM9PjB14 7S4hlRy9rUJ6YrEWP3Ok0vL5Xg/5gsb3WYtycl7+MzDFJkWdU52qO9QErw2xmp6OELUM KMgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe; bh=QUqeZuaS8XNJ9MjZpOyhbx1cr9GgmiTX6b2QLoNBsZg=; b=i6cKxCXh3atZKUlt59NjQDxzcfKknQ+BilZ5NX0oJaM3ItFymnWYkfZ25+JhN6aw5i Ly5tIMGLF9I4ncRXrqQqaOY6AsXjzJ0qstnG1jg7P0HZXJeMJXB3Ed7obhoG2cVdk1Sl VSAPvn7JRQOVSTQRC6bp3ym0A249W4pVc/RQMOijIycrqJzhw1zZ+x03D/8kwE+0gyGl kchYXACGzSjoZ5n8Cq+ictiNnQPo/SWiot5fE1vzDn3YSxos2A1f1uJPnWvnBfwU41in KrLcU3u4oFDqjR2qStzp4y5FnX32hD1w0WcxtoQ9CQeZHONRvCTFIfV2cw5w7ZOizIPu xXhA== X-Gm-Message-State: AD7BkJJRhS9kRGInIJrSlC/hlls5QSelIL3tN9A09rX+awKoNGEOtDBvseXOHQKRlntuyw== X-Received: by 10.25.160.207 with SMTP id j198mr2153439lfe.4.1457281279078; Sun, 06 Mar 2016 08:21:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.17.137 with SMTP id 131ls504631wmr.17.canary; Sun, 06 Mar 2016 08:21:17 -0800 (PST) X-Received: by 10.194.85.161 with SMTP id i1mr20618346wjz.95.1457281277454; Sun, 06 Mar 2016 08:21:17 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr. [80.12.242.126]) by mx.google.com with ESMTPS id h12si5125568wme.92.2016.03.06.08.21.17 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 06 Mar 2016 08:21:17 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.126; Original-Received: from new-host.home ([2.10.6.122]) by mwinf5d60 with ME id SgMG1s0092dxr8q03gMGVR; Sun, 06 Mar 2016 17:21:17 +0100 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sun, 06 Mar 2016 17:21:17 +0100 X-ME-IP: 2.10.6.122 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: Original-Sender: std-proposals@isocpp.org List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24990 Archived-At: This is a multi-part message in MIME format. --------------070604040300020203050503 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 06/03/2016 02:17, 'Walt Karas' via ISO C++ Standard - Future=20 Proposals a =C3=A9crit : > On Saturday, March 5, 2016 at 7:27:24 PM UTC-5, Nicol Bolas wrote: > > On Saturday, March 5, 2016 at 7:09:11 PM UTC-5, Walt Karas wrote: > > On Saturday, March 5, 2016 at 2:21:06 AM UTC-5, Vicente J. > Botet Escriba wrote: > > Le 05/03/2016 03:08, 'Walt Karas' via ISO C++ Standard - > Future Proposals a =C3=A9crit : >> >> >> On Friday, March 4, 2016 at 8:22:12 PM UTC-5, Nicol Bolas >> wrote: >> >> On Friday, March 4, 2016 at 2:53:26 PM UTC-5, Walt >> Karas wrote: >> >> Personally I'm more interested in a generic >> endiance-swap function template. The books will >> be open in 2017, new features will be made, I'm >> selfishly thinking of the needs on my own turf.=20 >> But why not do it in a way that is more general, >> provides for multiple needs? >> >> >> Yes... that's what /reflection/ will do. Your way is >> the more special-case and restrictive way. >> >> >> Are there other papers proposing support for reflection, >> besides p0255r0 ? >> > > Yes, look at > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/ > . > > Vicente > > > I think it's a bad choice to not seriously consider a class > introspection/reflection capability that can support providing > comparison operators as library templates. Maybe these do, > but it's not clear to me. > It depends if yous data is private or not. It is not clear yet what we=20 could be able to do reflecting private data. > > > ... why bother? With default operators > , > generating comparison operators won't be a significant use case > for reflection. Now, that doesn't mean you won't want to do it > sometimes. But most of the time, no. > > Also, just because one reflection proposal doesn't have something > doesn't mean that others won't. Compile-time reflection is hard to > get right. > > > Experience has shown that good layered architectures are generally=20 > advantageous. A rule of thumb for a good layered architecture is to=20 > have one capability in a lower layer that supports multiple=20 > capabilities in a higher layer. As opposed to supporting just one or=20 > some or all of those multiple capabilities in the lower layer. The=20 > base language is the lowest layer of the C++ architecture. Therefore,=20 > I think it's likely to be better to have a capability in the base=20 > language that allows for support of reasonably good generic comparison=20 > operators, generic stream input/output operators, generic std::hash,=20 > maybe generic JSON/XML input/output, etc using library code above the=20 > base layer. > I believe that we agree all here. We just need a proposal that has=20 enough consensus :) Vicente --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/56DC58FC.9020009%40wanadoo.fr. --------------070604040300020203050503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 06/03/2016 02:17, 'Walt Karas' via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:
On Saturday, March 5, 2016 at 7:27:24 PM UTC-5, Nicol Bolas wrote:
On Saturday, March 5, 2016 at 7:09:11 PM UTC-5, Walt Karas wrote:
On Saturday, March 5, 2016 at 2:21:06 AM UTC-5, Vicente J. Botet Escriba wrote:
Le 05/03/2016 03:08, 'Walt Karas' via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:


On Friday, March 4, 2016 at 8:22:12 PM UTC-5, Nicol Bolas wrote:
On Friday, March 4, 2016 at 2:53:26 PM UTC-5, Walt Karas wrote:
Personally I'm more interested in a generic endiance-swap function template.=C2=A0 The books will be open in 2017, new features will be made, I'm selfishly thinking of the needs on my own turf.=C2=A0 But why not do it in a w= ay that is more general, provides for multiple needs?

Yes... that's what reflection will do. Your way is the more special-case and restrictive way.

Are there other papers proposing support for reflection, besides p0255r0 ?

Yes, look at

http://www.open-std.org/jtc1/sc22/wg21/do= cs/papers/2016/.

Vicente

I think it's a bad choice to not seriously consider a class introspection/reflection capability that can support providing comparison operators as library templates. =C2=A0Maybe these do, but it's not clear to me= ..
It depends if yous data is private or not. It is not clear yet what we could be able to do reflecting private data.

... why bother? With default operators, generating comparison operators won't be a significant use case for reflection. Now, that doesn't mean you won't want to do it sometimes. But most of the time, no.

Also, just because one reflection proposal doesn't have something doesn't mean that others won't. Compile-time reflection is hard to get right.

Experience has shown that good layered architectures are generally advantageous. =C2=A0A rule of thumb for a good layered architecture is to have one capability in a lower layer that supports multiple capabilities in a higher layer. =C2=A0As oppose= d to supporting just one or some or all of those multiple capabilities in the lower layer. =C2=A0The base language is the lowest layer of the C++ architecture. =C2=A0Therefore, I think it= 's likely to be better to have a capability in the base language that allows for support of reasonably good generic comparison operators, generic stream input/output operators, generic std::hash, maybe generic JSON/XML input/output, etc using library code above the base layer.

I believe that we agree all here. We just need a proposal that has enough consensus :)

Vicente

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/m= sgid/std-proposals/56DC58FC.9020009%40wanadoo.fr.
--------------070604040300020203050503-- .