220 5936 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Mixins for C++ Date: Wed, 28 Aug 2013 05:44:01 -0700 (PDT) Lines: 229 Approved: news@gmane.org Message-ID: References: <787081f7-fb40-4507-907d-259318ef2000@isocpp.org> <1c80b902-4e65-4f4b-a5d7-8953dbf6df05@isocpp.org> <7035c144-8350-40d4-bf23-03ab7aa7fe53@isocpp.org> <816418a5-e8cd-4a26-ba9a-81ab55277748@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_133_33278058.1377693841709" X-Trace: ger.gmane.org 1377693841 30491 80.91.229.3 (28 Aug 2013 12:44:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Aug 2013 12:44:01 +0000 (UTC) Cc: cornedbee@google.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMKHJ4B6MARBEXB66IAKGQE77EP24Q@isocpp.org Wed Aug 28 14:44:05 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f70.google.com ([209.85.216.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VEf6R-0000j9-Of for gclcip-std-proposals@m.gmane.org; Wed, 28 Aug 2013 14:44:04 +0200 Original-Received: by mail-qa0-f70.google.com with SMTP id ii20sf695297qab.9 for ; Wed, 28 Aug 2013 05:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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:content-type; bh=YIQcFM7qjjrVk2CuNVVACg81R1wZzEBnENXvdmje9ws=; b=ReEv1FFxX+Jk5fZ1tsMqDQ4ZoOIFf9BEbdYBrH75/Icorf8CkLEng2Te3QMCZy+yyU vkzFNFynsUk4ok2GkacocdldJQLBet89abSn+vQWItFLaBRXoulmiPmeBTpGanrnKHwx QmMd0Q49lUdCoCzoAX+RuPC0Rbn9+Bhutc/h1jXRXPxcBsc3YIO01D5+PKj+zyW+ZBYZ fQY9PvnTXJ+6jcr9azxEL4aZGGh03HVQTqDA38nDuT7e3z86/+PC0RfrUiwxR9IRPUHq 584KdsPGCQMMzU8AsTErWbNBhisBlHGO1MQ0qx+EMVdPV5vpL+iUeXS82ZtHYu1BMH7V tKPg== X-Received: by 10.236.108.233 with SMTP id q69mr9853304yhg.11.1377693842886; Wed, 28 Aug 2013 05:44:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.131.68 with SMTP id ok4ls331529qeb.41.gmail; Wed, 28 Aug 2013 05:44:02 -0700 (PDT) X-Received: by 10.49.132.231 with SMTP id ox7mr2021qeb.35.1377693842299; Wed, 28 Aug 2013 05:44:02 -0700 (PDT) In-Reply-To: <816418a5-e8cd-4a26-ba9a-81ab55277748@isocpp.org> X-Original-Sender: lrdxgm@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:5936 Archived-At: ------=_Part_133_33278058.1377693841709 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 2013. augusztus 28., szerda 14:30:47 UTC+2 id=F5pontban corn...@google.com = a=20 k=F6vetkez=F5t =EDrta: > > > > On Wednesday, August 28, 2013 2:02:38 PM UTC+2, R=F3bert D=E1vid wrote: >> >> >> That's new: In every single language out there, mixin is a type. While= =20 >> C++ does not have to follow the same path, I think it is a bad idea to h= ave=20 >> something that is behaved differently than what every programmer with=20 >> experiences in other languages think. Please don't name it mixin, if thi= s=20 >> says like it. >> > > D's template mixins are not types. (They are very close to macros.) > Scala has mixins, but calls them traits. > PHP has what I want, but calls it traits. > Ruby's modules provide the same functionality, but it's referred to as=20 > mixin functionality. > Rust has traits, which are like interfaces, but mostly used for bounds in= =20 > generics. > > I could call the new feature "traits", but that name is already used by= =20 > the standard library (iterator_traits, char_traits), and reusing it would= =20 > be far more confusing than taking the already-muddled name mixins. > =20 > >> >> It's a pack of code. >>> >>> >> Soooo.. a macro? What's *wrong* with macros, besides the awkward=20 >> "generally good idea not to use them" argument? >> > > Failure to integrate into the language. Failure to respect namespaces.=20 > Failure to understand templates passed as arguments (have you ever found= =20 > the , between your template arguments being interpreted as separating you= r=20 > macro arguments?). Failure to provide decent debugger support on many=20 > platforms. Need I go on? > =20 > >> How about this macro-based solution to the problem: >> >> struct base { >> virtual base& foo() =3D 0; >> virtual base& bar() =3D 0; >> }; >> >> #define MIXIN_FOO \ >> > > Argh, line continuations! Completely different from the rest of C++? > =20 > >> >> int value; \ >> __THIS_CLASS__& foo() override; >> > > What if value is not supposed to be public? What about foo? Where does=20 > __THIS_CLASS__ come from? > >> >> struct derived : public base >> { >> MIXIN_FOO >> MIXIN_BAR >> > > What is the active access specifier here? > > Macros are a hack. Every use of macros indicates a place where the core= =20 > language is lacking. > > Macros are part of the language. It will not go away. We have to live with= =20 this fact. But with *improvements* (sorry, but everyone seem to miss that this is my= =20 point) it could also work in the place of mixins. Same way as MI / CRTP=20 could. Either way, with "small" standard changes you could have what you=20 need (with different syntax), and the language doesn't need an extra=20 ~hundred pages describing every single current feature's interaction with= =20 the new mixin feature. Regards, Robert --=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_133_33278058.1377693841709 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable


2013. augusztus 28., szerda 14:30:47 UTC+2 id=F5po= ntban corn...@google.com a k=F6vetkez=F5t =EDrta:


On Wednesday, August 28, 2013 2= :02:38 PM UTC+2, R=F3bert D=E1vid wrote:

That's new: In every single language out the= re, mixin is a type. While C++ does not have to follow the same path, I thi= nk it is a bad idea to have something that is behaved differently than what= every programmer with experiences in other languages think. Please don't n= ame it mixin, if this says like it.

D's template mixins are not types. (They are very close to macros.= )
Scala has mixins, but calls them traits.
PHP has what= I want, but calls it traits.
Ruby's modules provide the same fun= ctionality, but it's referred to as mixin functionality.
Rust has= traits, which are like interfaces, but mostly used for bounds in generics.=

I could call the new feature "traits", but that n= ame is already used by the standard library (iterator_traits, char_traits),= and reusing it would be far more confusing than taking the already-muddled= name mixins.
 

It's a pack of code= ..


Soooo.. a mac= ro? What's wrong with macros, besides the awkward "generally good id= ea not to use them" argument?

F= ailure to integrate into the language. Failure to respect namespaces. Failu= re to understand templates passed as arguments (have you ever found the , b= etween your template arguments being interpreted as separating your macro a= rguments?). Failure to provide decent debugger support on many platforms. N= eed I go on?
 
How about this macro-based solution to the problem:=

=
struct base {
 = virtual base&= amp; foo() =3D= 0;
  = virtual= base&a= mp; bar= () =3D<= /span> 0;
<= span style=3D"color:#660">};

#define MIXI= N_FOO  \

Argh, line continuations! Comple= tely different from the rest of C++?
 

&= nbsp; int value; \  __THIS_CLASS__& foo() override;

What if value is not supposed to be public? What about fo= o? Where does __THIS_CLASS__ come from?

struct derived = : public base
{
  MIXIN_= FOO
  MIXIN_BAR

What is the active access specifier here?
=
Macros are a hack. Every use of macros indicates a place whe= re the core language is lacking.


Macros are part of the language. It will not go away. We have to live= with this fact.
But with improvements (sorry, but everyone seem to miss that this is my point) it could also= work in the place of mixins. Same way as MI / CRTP could. Either way, with= "small" standard changes you could have what you need (with different synt= ax), and the language doesn't need an extra ~hundred pages describing every= single current feature's interaction with the new mixin feature.

Re= gards, Robert

--
 
---
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-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/<= /a>.
------=_Part_133_33278058.1377693841709-- .