220 12063 <53D225F4.90909@eudoxos.de> article Path: news.gmane.org!not-for-mail From: Roland Bock Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Mixins for C++ Date: Fri, 25 Jul 2014 11:40:04 +0200 Lines: 355 Approved: news@gmane.org Message-ID: <53D225F4.90909@eudoxos.de> References: <787081f7-fb40-4507-907d-259318ef2000@isocpp.org> <8344e51d-d912-4bd9-add3-233f4b0370bf@isocpp.org> <53CDF8AF.5050400@wanadoo.fr> <53D0DB86.3060103@eudoxos.de> <53D14B6B.5080202@wanadoo.fr> <53D1514A.2010008@eudoxos.de> <53D18E90.4010901@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040206030001060404060909" X-Trace: ger.gmane.org 1406281216 20384 80.91.229.3 (25 Jul 2014 09:40:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jul 2014 09:40:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCO7PYWVVELRB56LZCPAKGQEHMTBDNY@isocpp.org Fri Jul 25 11:40:09 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-we0-f200.google.com ([74.125.82.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XAbyz-0002o8-6h for gclcip-std-proposals@m.gmane.org; Fri, 25 Jul 2014 11:40:09 +0200 Original-Received: by mail-we0-f200.google.com with SMTP id t60sf3083290wes.7 for ; Fri, 25 Jul 2014 02:40:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=yPaXEQG2yAl2JTBG+QO3SdYqh/QnOaMp09t4dg+kJTk=; b=BxfXiQAV2nASfmIT0VKkO2DyTUDTd5cuvgcFcTpcHJ/Rv2YI7p/ff58rkkl6lTji2J W5SsQkAEL7Wayek83xDrIi/4n37V3JnZP64KRGWkWm47CTBDA+jyWACeZUhjyZW4MtmA N4OIvZbvErrecLIRdX/XRmLZ8/Tj/b7ZZ1ywO3thHbawp5MQFk3oVOZ8k+DXXJiqmxNx gPuVmlP3xVqwtjmcpMkIn3uVFnLx9gb4r6OrAMESutKCNSgaeG+1M7H2LZgTMkTWriFV VdQjOq75XZNfzww6mMq+10aBT6wngqPPWbOflFzkZZGH11OCJJ4HWsKY/koa1jNMEyUR kOKg== X-Gm-Message-State: ALoCoQkshaVd5ECPWlLNRIA3mOHrSqn+s1fA3z+2mpmGQ1l5hewU8dwqUADhn68D/ZcaqpD07tK2 X-Received: by 10.152.20.199 with SMTP id p7mr1389131lae.3.1406281208603; Fri, 25 Jul 2014 02:40:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.211.70 with SMTP id na6ls68710wic.7.canary; Fri, 25 Jul 2014 02:40:07 -0700 (PDT) X-Received: by 10.181.13.112 with SMTP id ex16mr3596848wid.58.1406281207441; Fri, 25 Jul 2014 02:40:07 -0700 (PDT) Original-Received: from mout.kundenserver.de (mout.kundenserver.de. [212.227.126.131]) by mx.google.com with ESMTPS id vl8si16660460wjc.152.2014.07.25.02.40.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jul 2014 02:40:07 -0700 (PDT) Received-SPF: none (google.com: rbock@eudoxos.de does not designate permitted sender hosts) client-ip=212.227.126.131; Original-Received: from [172.30.200.118] ([194.97.158.70]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0LknrN-1Wcv7j2zuH-00aiCK; Fri, 25 Jul 2014 11:40:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <53D18E90.4010901@wanadoo.fr> X-Provags-ID: V02:K0:ZVXuDpzAKUsvQ+ywiBPnzw7TgyOC1oxdFd4C2JWmEtx 1K9Mqr8zqfWO0HAVLV67qZOoODWV6bF9j1M/vzZq6HKGxH8bhH pFNi+OFb6hKWH6oSxx9GgyzOXbG3ry16sG3HZ0nOs+kf/oSlSQ RLSARQydYbjh7OUIXKakG+bDt93IcbUeB/uvauSwZs6XnMofAc 0+bmlLBPwQUk0QenW6pb6CjWKRMTrBBNUL0vMyZUqryVGKNqGu YtiyAKOVhwBTkm2weM7lUOGo3JpgpnN+QNO1T5oP9EjtgtdM90 S8hIlHlLH3ltE/SFZu8NgVBrccP56rjACUa1OjdirdM9WqVApU xFBsXx7IvCwh2d0n/B5g= X-Original-Sender: rbock@eudoxos.de X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: rbock@eudoxos.de does not designate permitted sender hosts) smtp.mail=rbock@eudoxos.de 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:12063 Archived-At: This is a multi-part message in MIME format. --------------040206030001060404060909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-07-25 00:54, Vicente J. Botet Escriba wrote: > Le 24/07/14 20:32, Roland Bock a =E9crit : >> On 2014-07-24 20:07, Vicente J. Botet Escriba wrote: >>> Le 24/07/14 12:10, Roland Bock a =E9crit : >>>> On 2014-07-22 07:37, Vicente J. Botet Escriba wrote: >>>>> Le 28/08/13 01:43, Sebastian Redl a =E9crit : >>>>>> >>>>>> >>>>>> On Wednesday, August 28, 2013 12:50:14 AM UTC+2, Klaim - Jo=EBl >>>>>> Lamotte wrote: >>>>>> >>>>>> =20 >>>>>> >>>>>> 3.=20 >>>>>> >>>>>> Now if mixins have accessors inside, there seem to be several >>>>>> ways possibilities: >>>>>> >>>>>> >>>>>> You have pretty much enumerated the access possibilities given >>>>>> the current access specifiers. But my worry goes beyond just >>>>>> access and concerns visibility: >>>>>> >>>>>> template >>>>>> mixin Foo { >>>>>> using my_secret_helper_type =3D complicated_metaprogram; >>>>>> // how do I keep my_secret_helper_type from colliding with >>>>>> types in embedding classes? >>>>>> // I can't open a namespace here, but I don't want to start >>>>>> with prefixes again >>>>>> >>>>>> mixin: >>>>>> using this_can_never_conflict =3D other_metaprogram; >>>>>> // awesome, I can use these without worries, because they're >>>>>> truly local to this class >>>>>> } >>>>>> >>>>>> I see these options to solve this problem: >>>>>> 1) Do nothing. Have the users use prefixes. This seems extremely >>>>>> inelegant to me. >>>>>> 1a) Merge what can be merged, but otherwise error out, as I >>>>>> described in my original post. Marginally better than 1). >>>>>> 2) Have declarations in the embedding class shadow those in >>>>>> mixins. Except for overloads maybe? But what if two mixins >>>>>> conflict? Earlier shadows later? Later shadows earlier? >>>>>> Declarations co-exist but are ambiguous when accessed? >>>>>> 2a) Embedding class shadows mixins, functions don't overload, >>>>>> multiple mixins coexist and are ambiguous in access. This is the >>>>>> "let's pretend we're still mixing in CRTP base classes" model. >>>>>> But given that I want the model to be "these are put into the >>>>>> class", that's very unintuitive. >>>>>> 3) Provide mixin: or an equivalent way of allowing mixins to hide >>>>>> their implementation details, and have other conflicting parts >>>>>> generate an error. Sounds reasonable, except that, as I said, >>>>>> this would mean that mixins provide a feature that C++ doesn't >>>>>> otherwise have, and I'm worried that they'll be used for that >>>>>> feature alone, leading to obfuscated code. But maybe I shouldn't >>>>>> be worried about that. I can still worry about implementability, >>>>>> though. >>>>>> 3a) Combine 3) with the merging from 1a) for non-hidden things. I >>>>>> like this merging - it feels intuitive and right. But maybe >>>>>> that's just because of where I'm coming from. >>>>>> >>>>>> >>>>> >>>>> I think that mixins should follows the same rules as if they were >>>>> derived classes. In addition, I believe that mixins are syntactic >>>>> sugar of the CRTP idiom and that its semantics should be defined >>>>> as a transformation. I can post it if there is an interest in this >>>>> approach. >>>>> >>>>> Next follow the rules I find more convenient. >>>>> >>>>> <>-- >>>> Thanks for writing this down. I wanted to write pretty much the >>>> same for a few weeks now and never got to it :-) >>>> >>> You are welcome. >>>> Questions: >>>> >>>> * Would data members be supported as well? >>>> >>> Yes. Types would be supported also. >>>> >>>> * Would a mixin be able to access the class that it is used by >>>> (similar to CRTP where the base object can access the derived >>>> object)? >>>> >>> Yes. This is at least my intent. A mixin has access to all the parts >>> of its embedding class/mixin. This access rights need to be of >>> course transitive. >> Do you have an idea for the syntax of accessing the embedding >> class/mixin yet? > We could use final to make it explicit > > this->final::member > > > >>>> * >>>> >>>> >>>> >>>> >>>> For the things I have in mind, I would definitely need both items. >>>> >>>> >>> You wrote earlier that mixin semantics should be defined via a >>> transformation from CRTP. I'd be interested in that transformation. >>> Do you think that transformation could be used for a formal proposal? > I don't know if this is a good or bad idea. I know that the mixin > model I have in mind can be transformed to a CRTP implementation. The > CRTP implementation can give us the rules we want to emerge and make > it possible to prototype it. I consider it a good idea. I'd be happy with mixins being a more convenient way of expressing things you can do with CRTP with the benefit, that there is no inheritance involved. Regards, Roland --=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/. --------------040206030001060404060909 Content-Type: text/html; charset=ISO-8859-1
On 2014-07-25 00:54, Vicente J. Botet Escriba wrote:
Le 24/07/14 20:32, Roland Bock a écrit :
On 2014-07-24 20:07, Vicente J. Botet Escriba wrote:
Le 24/07/14 12:10, Roland Bock a écrit :
On 2014-07-22 07:37, Vicente J. Botet Escriba wrote:
Le 28/08/13 01:43, Sebastian Redl a écrit :


On Wednesday, August 28, 2013 12:50:14 AM UTC+2, Klaim - Joël Lamotte wrote:

 
3. 

Now if mixins have accessors inside, there seem to be several ways possibilities:

You have pretty much enumerated the access possibilities given the current access specifiers. But my worry goes beyond just access and concerns visibility:

template <typename T>
mixin Foo {
  using my_secret_helper_type = complicated_metaprogram<T>;
  // how do I keep my_secret_helper_type from colliding with types in embedding classes?
  // I can't open a namespace here, but I don't want to start with prefixes again

mixin:
  using this_can_never_conflict = other_metaprogram<T>;
  // awesome, I can use these without worries, because they're truly local to this class
}

I see these options to solve this problem:
1) Do nothing. Have the users use prefixes. This seems extremely inelegant to me.
1a) Merge what can be merged, but otherwise error out, as I described in my original post. Marginally better than 1).
2) Have declarations in the embedding class shadow those in mixins. Except for overloads maybe? But what if two mixins conflict? Earlier shadows later? Later shadows earlier? Declarations co-exist but are ambiguous when accessed?
2a) Embedding class shadows mixins, functions don't overload, multiple mixins coexist and are ambiguous in access. This is the "let's pretend we're still mixing in CRTP base classes" model. But given that I want the model to be "these are put into the class", that's very unintuitive.
3) Provide mixin: or an equivalent way of allowing mixins to hide their implementation details, and have other conflicting parts generate an error. Sounds reasonable, except that, as I said, this would mean that mixins provide a feature that C++ doesn't otherwise have, and I'm worried that they'll be used for that feature alone, leading to obfuscated code. But maybe I shouldn't be worried about that. I can still worry about implementability, though.
3a) Combine 3) with the merging from 1a) for non-hidden things. I like this merging - it feels intuitive and right. But maybe that's just because of where I'm coming from.



I think that mixins should follows the same rules as if they were derived classes. In addition, I believe that mixins are syntactic sugar of the CRTP idiom and that its semantics should be defined as a transformation. I can post it if there is an interest in this approach.

Next follow the rules I find more convenient.

<>--
Thanks for writing this down. I wanted to write pretty much the same for a few weeks now and never got to it :-)

You are welcome.
Questions:
  • Would data members be supported as well?
Yes. Types would be supported also.

  • Would a mixin be able to access the class that it is used by (similar to CRTP where the base object can access the derived object)?
Yes. This is at least my intent. A mixin has access to all the parts of its embedding class/mixin. This access rights need to be of course transitive.
Do you have an idea for the syntax of accessing the embedding class/mixin yet?
We could use final to make it explicit

  this->final::member




For the things I have in mind, I would definitely need both items.


You wrote earlier that mixin semantics should be defined via a transformation from CRTP. I'd be interested in that transformation. Do you think that transformation could be used for a formal proposal?
I don't know if this is a good or bad idea. I know that the mixin model I have in mind  can be transformed to a CRTP implementation. The CRTP implementation can give us the rules we want to emerge and make it possible to prototype it.
I consider it a good idea. I'd be happy with mixins being a more convenient way of expressing things you can do with CRTP with the benefit, that there is no inheritance involved.

Regards,

Roland

--

---
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/.
--------------040206030001060404060909-- .