220 33796 <5d2c2db8-9774-4099-82d6-c97b909363ad@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: properties? Date: Thu, 10 Aug 2017 09:21:22 -0700 (PDT) Lines: 126 Approved: news@gmane.org Message-ID: <5d2c2db8-9774-4099-82d6-c97b909363ad@isocpp.org> References: <6ed2bd55-5538-418f-8f1a-263a9958babd@isocpp.org> <10557c71-2b0f-6675-305e-1267eeda1ed6@gmail.com> <05214462-9ca7-a5c8-018a-4a05faf02f7c@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1030_1031566323.1502382083010" X-Trace: blaine.gmane.org 1502382088 6288 195.159.176.226 (10 Aug 2017 16:21:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 Aug 2017 16:21:28 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBA4QWLGAKGQEKYVXR7Y@isocpp.org Thu Aug 10 18:21:24 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dfqD1-0000vq-2B for gclcip-std-proposals@m.gmane.org; Thu, 10 Aug 2017 18:21:19 +0200 Original-Received: by mail-yw0-f200.google.com with SMTP id n140sf17207999ywd.13 for ; Thu, 10 Aug 2017 09:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=HOsmw15FiaWGqqBaKtx/9FochR1iTddko13ovXCF0x0=; b=F8/TCdVW65qmqF2P1l4dEEMeHZaIC1nv0g8Nq++0ikXJtocUsQy/lhxycfpeFErQXU dHITHVmWsR4tRVKCPYqpfQLrcv/A6U/WsQy9KpZG0UNH9yNrfvUq1iXUKOJMeDJJoqlc xwGGL1OeKllF/l1u7e7Rkii9THOt5BpnIaI7LahTEPyoPiSu9hzHloRKRnI7VImiu+VM LH/YkWEpsZ2XcOUMZJ++cbNseCAGJBut7k8AF61+HsvIfEXAv3jJHP9nTSNpd13t8USO h/Lt+guk5ANb08gvEEzKFOMK/wGD7zJOt2Gm+SK4EHKU3xz2aOEaKycDLeNMwxTOWfWJ kmXQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=HOsmw15FiaWGqqBaKtx/9FochR1iTddko13ovXCF0x0=; b=PZk/y4Pr+j/wc/zJnbQrPA5+WEw/uUJkNi08nU5H5ZYml3xP/RzlZxnqJ2BDB2K3YO KPjbkyts4WBd5JsJ6Nr/6HWTJj50uEAa8FjazwcThev/M9fYWL/06ILGgCK0+w8oAYhF z8WLU0Bp+2HWx5ANO0vSX3bkUTQppsF2/cvx9f0Jf0vOQRQu/8ryRdMmWrW2pVjakCsA LD4oWqxoNEuH04y2X5YyUZWawouAUcS7mmOmOPSuIhHHs0Mx/zkZJPJ+PZs1NFfMqVRg nd0yqvPquSvMXL22dMaEsJf0hSkmqPGafDvNStvJnkKpcbu4f9ZuL/ZpJJPYpZ0XgpNK fbaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=HOsmw15FiaWGqqBaKtx/9FochR1iTddko13ovXCF0x0=; b=FCG8N8tFuGWbcrqpy1RPppvZQXX+0vS22GvNzzlNG1yBrSmz88UPAe04RuiP8DSHDD swbr4sMrRF3gHKbhEZaHIEGspsUW9qxtCy2h4iOTH1DYVNAb/akWbVbvU2ifJJ4HF0Bw JW2jKlWrUGu3AjmEfpavGrjrXwC4BEdkFKgRfhE4TkL2YpRW2wfApgc9YJ63DaGIFt65 3V/16bbbjpocuy+ddHe5rJm7HiTN1/dDVAAXOb1QqrL0hCpBEftTrZ9jK4eP3A6ugWYd SkCnbzeTcN3Acrabx2A1KnS+QHkoKmUId1IqpqZUGvUD8l7Nsoo0GLSmBVGewWtUGlaH 6trA== X-Gm-Message-State: AHYfb5hZ0Hs5DdmrtyseUAmkXwBxP8cjW6uf8A4lu+5iYe2c+xF9GCWU m0nbiOgYT9owX9OK X-Received: by 10.129.170.15 with SMTP id i15mr7604534ywh.163.1502382084930; Thu, 10 Aug 2017 09:21:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.244.75 with SMTP id u11ls7912192iti.14.canary-gmail; Thu, 10 Aug 2017 09:21:23 -0700 (PDT) X-Received: by 10.31.151.77 with SMTP id z74mr76459vkd.3.1502382083492; Thu, 10 Aug 2017 09:21:23 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:33796 Archived-At: ------=_Part_1030_1031566323.1502382083010 Content-Type: multipart/alternative; boundary="----=_Part_1031_946003205.1502382083011" ------=_Part_1031_946003205.1502382083011 Content-Type: text/plain; charset="UTF-8" On Thursday, August 10, 2017 at 10:40:58 AM UTC-4, Ville Voutilainen wrote: > > On 10 August 2017 at 17:08, Matthew Woehlke > wrote: > > Ah. Of course, mixins are sufficiently wide-spread that figuring those > > out is almost certainly worthwhile in its own right. (I've always > > thought so, anyway.) > > > > Maybe someone would be interested in taking up the torch on those? > > > I daresay we should see how much we can get via reflection, and then > figure out whether we want > to add specific facilities. > This is not a problem reflection can solve. Or at least, not the problem I was encountering with CRTP-based mixins. That problem being the fact that the derived class (the class being mixed into) is *incomplete* at the point where the mixin is being instantiated. That's the catch-22: you need a way to augment a type with new stuff, but you also need a way to access the stuff that was previously added to the type. And as I understand, you cannot invoke reflection on an incomplete type. And even if you could reflect over a partially complete type, you wouldn't be able to access members that haven't been declared yet. And since CRTP-based mixins are used as base classes, then pretty much everything about the derived class has not yet been declared. A proper mixin facility needs the following three properties: 1: The ability for a type to add the mixin to itself, such that the mixin's declarations are able to have access to any previously-declared members in the type. 2: The ability for a type that gets mixed-into to access the mixin's declarations as if they were its own. 3: The ability to convert a pointer/reference to a type into a pointer/reference to the mixin it uses, providing access only to the mixin's interface. Note: I'm not sure that #3 is really needed. But at the same time, it seems like an *exceedingly* useful thing to have, since it allows you to have external operator overloading and the like. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d2c2db8-9774-4099-82d6-c97b909363ad%40isocpp.org. ------=_Part_1031_946003205.1502382083011 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, August 10, 2017 at 10:40:58 AM UTC-4, Ville V= outilainen wrote:
On 10 August = 2017 at 17:08, Matthew Woehlke <mwoehlk...@gmail.com> wrote:
> Ah. Of course, mixins are sufficiently wide-spread that figuring t= hose
> out is almost certainly worthwhile in its own right. (I've alw= ays
> thought so, anyway.)
>
> Maybe someone would be interested in taking up the torch on those?


I daresay we should see how much we can get via reflection, and then
figure out whether we want
to add specific facilities.

This is not a prob= lem reflection can solve. Or at least, not the problem I was encountering w= ith CRTP-based mixins. That problem being the fact that the derived class (= the class being mixed into) is incomplete at the point where the mix= in is being instantiated.

That's the catch-22: you need a way to= augment a type with new stuff, but you also need a way to access the stuff= that was previously added to the type. And as I understand, you cannot inv= oke reflection on an incomplete type.

And even if you could reflect = over a partially complete type, you wouldn't be able to access members = that haven't been declared yet. And since CRTP-based mixins are used as= base classes, then pretty much everything about the derived class has not = yet been declared.

A proper mixin facility needs the following three= properties:

1: The ability for a type to add the mixin to itself, s= uch that the mixin's declarations are able to have access to any previo= usly-declared members in the type.

2: The ability for a type that ge= ts mixed-into to access the mixin's declarations as if they were its ow= n.

3: The ability to convert a pointer/reference to a type into a po= inter/reference to the mixin it uses, providing access only to the mixin= 9;s interface.

Note: I'm not sure that #3 is really needed. But = at the same time, it seems like an exceedingly useful thing to have,= since it allows you to have external operator overloading and the like.

--
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/msgid/std-proposals/5d2c2db8-9774-4099-82d6-c97b909363ad= %40isocpp.org.
------=_Part_1031_946003205.1502382083011-- ------=_Part_1030_1031566323.1502382083010-- .