220 11970 <53CA7CD5.5010208@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Mixins for C++ Date: Sat, 19 Jul 2014 16:12:37 +0200 Lines: 508 Approved: news@gmane.org Message-ID: <53CA7CD5.5010208@wanadoo.fr> References: <787081f7-fb40-4507-907d-259318ef2000@isocpp.org> <5221A041.1060001@wanadoo.fr> <15667a97-e6f3-46fb-b346-6f248b5815cf@isocpp.org> <5224C95D.8040608@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090004030703080301080604" X-Trace: ger.gmane.org 1405779167 31050 80.91.229.3 (19 Jul 2014 14:12:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Jul 2014 14:12:47 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDH67CONY4PBBVXZVGPAKGQEY56LUCA@isocpp.org Sat Jul 19 16:12:40 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f198.google.com ([209.85.212.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X8VNP-0006wU-Ri for gclcip-std-proposals@m.gmane.org; Sat, 19 Jul 2014 16:12:39 +0200 Original-Received: by mail-wi0-f198.google.com with SMTP id ho1sf1383606wib.1 for ; Sat, 19 Jul 2014 07:12:39 -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=HOev/PEkGYlqqUVZQGVyLzGu/F4aXIXSChat8l1TfLE=; b=e83CIT3HPFN24uhPl1a+1Xr83NsO8wzXMFn9tyd8fP4ZuoRDnhvYcURTRSV1P09jCy JBsW8gzAX7oKQn6STtqDEjcz2pSfgsofYy4qxt9ACVz7RzHxPOT01v48s1N+JnqIiYP5 M5l9vLj/pxinJxRqQtllMqzbRiUtDwYWTOAh80mLfOod+NINZFb8tLR2E5d/ihTWmN3a N5pa95P6VyXfHD7Na/L1UksB8he9bFEKoPypgaJcj6BzA+hkg25kKFwS9KnYczzFl6uQ sdmzEScxTx675BIc5ux0XAt1aKYr7lf38n6DQmaD+dZQt3WVDciniJuXUa1GQZlJDTNV 0YGw== X-Gm-Message-State: ALoCoQkFQQYCRPErr1QdSsfbF9zd/l6IlX2U1kIsqlvvGswl7l/B24cKphdHq0QSnV1sGwAHbTp5 X-Received: by 10.180.13.99 with SMTP id g3mr1148006wic.1.1405779159403; Sat, 19 Jul 2014 07:12:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.106.232 with SMTP id gx8ls76167wib.20.canary; Sat, 19 Jul 2014 07:12:38 -0700 (PDT) X-Received: by 10.194.192.201 with SMTP id hi9mr5606835wjc.28.1405779158057; Sat, 19 Jul 2014 07:12:38 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr. [80.12.242.123]) by mx.google.com with ESMTP id v8si17082537wjq.85.2014.07.19.07.12.37 for ; Sat, 19 Jul 2014 07:12:38 -0700 (PDT) Received-SPF: none (google.com: vicente.botet@wanadoo.fr does not designate permitted sender hosts) client-ip=80.12.242.123; Original-Received: from new-host.home ([81.53.187.130]) by mwinf5d36 with ME id UECd1o0072pEBw103ECdvQ; Sat, 19 Jul 2014 16:12:37 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sat, 19 Jul 2014 16:12:37 +0200 X-ME-IP: 81.53.187.130 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: vicente.botet@wanadoo.fr does not designate permitted sender hosts) smtp.mail=vicente.botet@wanadoo.fr 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:11970 Archived-At: This is a multi-part message in MIME format. --------------090004030703080301080604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Le 03/09/13 17:54, cornedbee@google.com a =E9crit : While doing some search about mixins I have found that I didn't replied=20 to this post :( Hoping this is not too late ;-) > > On Monday, September 2, 2013 7:22:37 PM UTC+2, Vicente J. Botet=20 > Escriba wrote: > > Le 02/09/13 16:51, corn...@google.com a =E9crit : >> Nested templates are simply ugly, and that's without trying to >> define some of the mixin's methods out-of-line; then you get to >> multiple template parameter lists, which I bet 90% of C++ >> programmers have never seen in production code, much less written. > Why would you need to define the mixin's methods out-of-line? > > > Every other construct in C++ allows out-of-line definition; why should=20 > it be impossible for mixins? I have not said that it is impossible. You said that it was just even=20 uglier. > >> >> class foo : public mixin X >> { >> }; >> >> >> This runs into the problems I mentioned about the completeness of >> foo within the mixin. > I don't see this as a problem, but a future of mixins. A mixin has > only sense once instantiated. > > > I don't understand what you mean by that. I meant a feature of mixins, not a future. > I want mixins to be able to refer to at least some members of the=20 > embedding class from the mixin body, not just the functions. Me too. We agree here. > >> Have you considered adding a self keyword instead of using this? >> >> >> For a moment, but I don't see the point. 'self' is completely >> impossible to add, since it is widely used as a variable/function >> name, and the new use would be in a context where a variable name >> can appear. If you know any other conveniently short and logical >> words that aren't already in wide use in expression context, I'd >> love to hear about them, though. > The keyword can be contextual. > > > No, it can't be. That's what I've been trying to say with "would be in=20 > a context where a variable name can appear". Contextual keywords only=20 > work if the new use for the keyword is in a context where no existing=20 > identifier could appear. For example, the 'final' and 'override'=20 > contextual keywords only appear after the class name of a class=20 > declaration and after the parameter list of a member function; places=20 > where neither type names nor variable/function names are allowed. This=20 > allows them to be contextual keywords. A 'self' keyword would have to=20 > appear in expression context, in the place where e.g. 'this' can=20 > appear as well. More importantly, a variable named 'self' can appear=20 > in this place, and that's why 'self' doesn't work as a contextual keyword= .. You are right it can not be contextual. On the Flat approach mixins can make use only of members visible from=20 the embedding class. On the Stack approach mixins can make use either of something under the=20 stack and we use this->base_type.member or something on top of the stack, visible from the embedding class and=20 we use self().member >> This is a good point. Relaying calls from one mixin to another is >> a use case I haven't considered so far. I have no good solution >> for this at the moment. > The alternative CRTP model would allow it without any trouble. > > > A "rewrite to base classes" semantic model would work for many use=20 > cases, but not for the class member access I want. Also,=20 > initialization order would get interesting, and dealing with multiple=20 > mixins implementing functions from each other or multiple pre-existing=20 > base classes would bring lots of complexity in the definition and the=20 > explanation of the feature. I agree that your base class model is simpler and easier to understand,=20 but less powerfully as the contribution of each mixin is exclusive, and=20 you can not support each mixing participating on a chain of=20 responsibility, as e.g. the trace() function I showed before. > Motivating example: > > struct Foo { virtual void foo() =3D 0; }; > struct Bar { virtual void bar() =3D 0; }; > mixin FooImpl { > virtual void baz() =3D 0; > void foo() { baz(); } > } > mixin BarBazImpl { > void bar() {} > void baz() {} > } > struct FooBar : Foo, Bar, mixin FooImpl, mixin BarBazImpl {}; > > Is the order of the mixins important here? What would the rewritten=20 > hierarchy look like? The mixins can have multiple base classes. let me use=20 __multiple<__pub, __pric to mean a mixin class inherits publicly=20 from X and privately from Y. The CRTP model would something like struct FooBar : BarBazImpl, __pub>>> {}; or struct FooBar : mixins< __multiple< __pub, __pub>, FooImpl,=20 BarBazImpl> {}; The main problem with this approach is the construction of the mixins=20 using direct C++. But I could hope that a compiler could do the expected=20 behavior, that is construct Foo, the Bar, then FooImpl and last BarBazImpl. > >> In the base class model, conflicting names just hide each other; >> they are not by themselves an error. But going with the model of >> inheriting conflicting names from multiple bases might be the >> best model for what I want to achieve after all. > Sorry, I don't understand. Are you telling inheriting from > multiple bases? > > > Yes. Think about what happens when you inherit from multiple classes=20 > that have members with the same name. I think those are the best=20 > semantics for mixins with conflicting names too. > I could agree the conflict arise for non-private data members, but it=20 should not arise for private ones and functions members. Note again that I'm not against a mixin feature, but IMHO the flat model=20 could be improved with a stack of mixins. I could be for any syntaxes if what is behind is a stack of mixins, either struct FooBar : Foo, Bar, mixin FooImpl, mixin BarBazImpl {}; or struct FooBar : Foo, Bar { using mixin FooImpl; using mixin BarBazImpl; }; Best, Vicente --=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/. --------------090004030703080301080604 Content-Type: text/html; charset=ISO-8859-1
Le 03/09/13 17:54, cornedbee@google.com a écrit :

While doing some search about mixins I have found that I didn't replied to this post :(
Hoping this is not too late ;-)

On Monday, September 2, 2013 7:22:37 PM UTC+2, Vicente J. Botet Escriba wrote:
Le 02/09/13 16:51, corn...@google.com a écrit :
Nested templates are simply ugly, and that's without trying to define some of the mixin's methods out-of-line; then you get to multiple template parameter lists, which I bet 90% of C++ programmers have never seen in production code, much less written.
Why would you need to define the mixin's methods out-of-line?

Every other construct in C++ allows out-of-line definition; why should it be impossible for mixins?
I have not said that it is impossible. You said that it was just even uglier.
  

class foo : public mixin X
{
};

This runs into the problems I mentioned about the completeness of foo within the mixin.
I don't see this as a problem, but a future of mixins. A mixin has only sense once instantiated.

I don't understand what you mean by that.
I meant a feature of mixins, not a future.
I want mixins to be able to refer to at least some members of the embedding class from the mixin body, not just the functions.
Me too. We agree here.
 
Have you considered adding a self keyword instead of using this?

For a moment, but I don't see the point. 'self' is completely impossible to add, since it is widely used as a variable/function name, and the new use would be in a context where a variable name can appear. If you know any other conveniently short and logical words that aren't already in wide use in expression context, I'd love to hear about them, though.
The keyword can be contextual.

No, it can't be. That's what I've been trying to say with "would be in a context where a variable name can appear". Contextual keywords only work if the new use for the keyword is in a context where no existing identifier could appear. For example, the 'final' and 'override' contextual keywords only appear after the class name of a class declaration and after the parameter list of a member function; places where neither type names nor variable/function names are allowed. This allows them to be contextual keywords. A 'self' keyword would have to appear in expression context, in the place where e.g. 'this' can appear as well. More importantly, a variable named 'self' can appear in this place, and that's why 'self' doesn't work as a contextual keyword.
You are right it can not be contextual.

On the Flat approach mixins can make use only of members visible from the embedding class.

On the Stack approach mixins can make use either of something under the stack and we use

  this->base_type.member

or something on top of the stack, visible from the embedding class and we use

  self().member




 
This is a good point. Relaying calls from one mixin to another is a use case I haven't considered so far. I have no good solution for this at the moment.
The alternative CRTP model would allow it without any trouble.

A "rewrite to base classes" semantic model would work for many use cases, but not for the class member access I want. Also, initialization order would get interesting, and dealing with multiple mixins implementing functions from each other or multiple pre-existing base classes would bring lots of complexity in the definition and the explanation of the feature.
I agree that your base class model is simpler and easier to understand, but less powerfully as the contribution of each mixin is exclusive, and you can not support each mixing participating on a chain of responsibility, as e.g. the trace() function I showed before.
Motivating example:

struct Foo { virtual void foo() = 0; };
struct Bar { virtual void bar() = 0; };
mixin FooImpl {
  virtual void baz() = 0;
  void foo() { baz(); }
}
mixin BarBazImpl {
  void bar() {}
  void baz() {}
}
struct FooBar : Foo, Bar, mixin FooImpl, mixin BarBazImpl {};

Is the order of the mixins important here? What would the rewritten hierarchy look like?
The mixins can have multiple base classes. let me use __multiple<__pub<X>, __pric<Y> to mean a mixin class inherits publicly from X and privately from Y.
The CRTP model would something like

struct FooBar :  BarBazImpl<FooBar, FooImpl<FooBar, __multiple< __pub<Foo>, __pub<Bar>>>> {};

or

struct FooBar :  mixins< __multiple< __pub<Foo>, __pub<Bar>>,  FooImpl, BarBazImpl> {};

The main problem with this approach is the construction of the mixins using direct C++. But I could hope that a compiler could do the expected behavior, that is construct Foo, the Bar, then FooImpl and last BarBazImpl.


In the base class model, conflicting names just hide each other; they are not by themselves an error. But going with the model of inheriting conflicting names from multiple bases might be the best model for what I want to achieve after all. 
Sorry, I don't understand. Are you telling inheriting from multiple bases?


Yes. Think about what happens when you inherit from multiple classes that have members with the same name. I think those are the best semantics for mixins with conflicting names too.
 

I could agree the conflict arise for non-private data members, but it should not arise for private ones and functions members.

Note again that I'm not against a mixin feature, but IMHO the flat model could be improved with a stack of mixins.

I could be for any syntaxes if what is behind is a stack of mixins, either

struct FooBar : Foo, Bar, mixin FooImpl, mixin BarBazImpl {};

or

struct FooBar : Foo, Bar {
  using mixin FooImpl;
  using mixin BarBazImpl;
};


Best,
Vicente

--

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