220 8101 <0bd0d5f0-8094-4272-b411-d014823d9021@isocpp.org> article Path: news.gmane.org!not-for-mail From: fmatthew5876@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Private extension methods Date: Tue, 10 Dec 2013 22:38:20 -0800 (PST) Lines: 416 Approved: news@gmane.org Message-ID: <0bd0d5f0-8094-4272-b411-d014823d9021@isocpp.org> References: <05028bfb-6f6f-4ee8-9a6e-7e6eaa3a877a@isocpp.org> <64d699c7-62e0-48ce-9c58-c9b7a6038832@isocpp.org> <1902602.AxIk4I1HBX@tjmaciei-mobl2> <52A79CD3.50802@wanadoo.fr> <52A7B319.1090308@gmail.com> <566b4320-4f64-4d14-ac61-6eb94c536967@isocpp.org> <52A803E2.6040203@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4365_21716991.1386743900243" X-Trace: ger.gmane.org 1386743897 27035 80.91.229.3 (11 Dec 2013 06:38:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Dec 2013 06:38:17 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBXMQUCKQKGQE4ERQ5BA@isocpp.org Wed Dec 11 07:38:22 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f72.google.com ([209.85.216.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VqdR8-0006M8-Kz for gclcip-std-proposals@m.gmane.org; Wed, 11 Dec 2013 07:38:22 +0100 Original-Received: by mail-qa0-f72.google.com with SMTP id f11sf661472qae.11 for ; Tue, 10 Dec 2013 22:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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 :content-type; bh=ezK2wXAi4s0L9HNQApzuj06/6BWtc51MQrnSv0dkNQo=; b=JDH256krWHq3TFAFqIHu6MhxFLwPyPaVV7OCMmn3PjeV8dwAg4kin32OV0MWvhGzKh dRK2+YuwjWNsWLHTsW573C9liDllkFkkIcqOOYw+BMYK9tiLaA7YTint4FNzenZ6ZAi6 wWUviTVBzbH+AZge96sE72rsLO1rMBJ/fCEkDyIfZTSfaXpjLmglOCxgE8ydWNBQqQRb GYdcgW7ER9T0P2+Iz7j84PxVk3AUhtgtEa4XGPpIo0xSM8u51+dmpMS+7iIP6xOhnVp7 WFKMTbtxtmarDqvKk7gWUJwdWwyFhCTZ+oe/E96iO1znMI2Mp2n3KJly96N+ecafQTBC fCtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=ezK2wXAi4s0L9HNQApzuj06/6BWtc51MQrnSv0dkNQo=; b=mE5bnsvaPDPvTKFtqYG3ov/C9tbFEw58d7lKlfPtBzwjRMhL3F+WPv2Eba/CxW36qn /YUP61A2nIC5AfrO02hq5Y+LOip3OiKj6i+cug/QKGgxg/Sb3woGVQjy0R4AtE9yqJ9P gTJLA1wreI9eybAHYFPxwFr1+BLwC0RCNJyX4zgvet5Z1EzTIv+foCojmdvLmugCDOoj yO1t23yABTtayZ0w4OvkJOEqV3gBkxok4FLR93abCXNkw7r27Z6x8LjHobxQTkFB25XW U35H8B9dyuhrhsy+U33SujgvDUWycisCdsrHmu8pwasvOWyweI8Mo09LJG9U+WAQ/CaE Ip5w== X-Gm-Message-State: ALoCoQk+QNcr/hg+5YlzWByZF9xTG2h8UVoawJzgKjzDAtiOtvnEaJbWAERXrwuxNquz2+vc4iCX X-Received: by 10.236.111.73 with SMTP id v49mr1843605yhg.46.1386743901550; Tue, 10 Dec 2013 22:38:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.205.163 with SMTP id lh3ls1407608obc.84.gmail; Tue, 10 Dec 2013 22:38:20 -0800 (PST) X-Received: by 10.182.72.131 with SMTP id d3mr324obv.39.1386743900945; Tue, 10 Dec 2013 22:38:20 -0800 (PST) In-Reply-To: <52A803E2.6040203@wanadoo.fr> X-Original-Sender: fmatthew5876@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:8101 Archived-At: ------=_Part_4365_21716991.1386743900243 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, December 11, 2013 1:19:14 AM UTC-5, Vicente J. Botet Escriba= =20 wrote: > > Le 11/12/13 03:55, fmatth...@gmail.com a =E9crit : > =20 > Wow lots of comments. =20 > > =20 > =20 >> I don't see any benefit to inline calls to private functions that would= =20 >> be defined in a .cc file as your >> >> //Forward declaration of a private extension method >> void Foo::_priv2(); >> >> //Inlined public method calls the private extension method >> inline void Foo::pub2() { _priv2(); } >> >> >> inlining the _priv2() call would result on the same code. >> >> >> I don't see neither the needed to declare new private functions on=20 >> different files. Could you explain where this could be useful. >> > > I've had plenty of situations where a class is implemented in multiple= =20 > cc files in order to better separate concerns. I find myself doing this= =20 > more for classes that implement "Application Logic." Usually singular=20 > concepts such as data structures are implemented in one cc file, if not= =20 > entirely in the header due to templates. > > In this situation, you would have your public header with the class=20 > definition, a private header with some extension method declarations, and= =20 > finally multiple cc files with the definitions and possibly more file=20 > scoped extension methods as needed. > =20 > I understand your use case. Reducing compilation dependencies between=20 > implementation of different classes seems to me the problem to address.= =20 > While taking care of the case where multiple files implements a specific= =20 > class would be nice, it is for me a corner case. =20 > Reducing dependencies by minimizing the interface is the name of the game= =20 here. I agree that multiple source files is a corner case, but I'd like to= =20 support it as it is useful sometimes.=20 > =20 > Declaring an extension method in the same header as the class definition= =20 > has little if no value. That's merely a stylistic choice. I included it= =20 > just to show the possibilities. > =20 > So we agree this is not a must have. > Yes, but if you can declare a private extension method just like a regular= =20 free function, there's no reason shouldn't be able to do it in the class=20 header. I suppose one corner use case is conditional compilation. One=20 version may want to call an inline PEM, while another does not (PEM is=20 #ifdefed out). > =20 > >> >> >> Maybe the idiom could be adapted to a language proposal that could avoid= =20 >> the cumbersome use of the that variable. It could consists in declaring = a=20 >> pseudo-struct declaration e.g. private Foo, that could contain only=20 >> functions. These functions would be accessible only by the class Foo and= =20 >> any friend of Foo. Of course, in order to other classes to be able to us= e=20 >> these private functions, the private pseudo-struct should be declared in= =20 >> another file. >> >> //foo.hh >> class Foo { >> public: >> Foo(); >> void pub1(); >> void pub2(); >> private: >> >> int _i; >> int _j; >> }; >> >> //foo.cc >> *private* Foo { >> //Definition of _priv1() >> void _priv1() { >> /* function body */ >> } //A new scoped private extension method. >> static void _priv3() { >> _i =3D 3; >> } >> }; >> >> =20 > This is an interesting idea. Essentially reopening the scope to add more= =20 > private stuff. Not only could you add new private methods but also privat= e=20 > typedefs and nested classes as well. In the old thread (see github for th= e=20 > link), someone was essentially proposing this idea. He wanted to use a=20 > concept of class namespaces, but I like your syntax better. > =20 > Note that for me the scope could be reopened only once. In order to avoid= =20 > that the user can do it on any class it would be better to restrict it to= =20 > class that have declared it. E.g. we could declare the class friend of=20 > itself. > Why the restrictions? Can you demonstrate a case where allowing this=20 feature everywhere would cause a problem? How is this better than using a= =20 nested class (see workarounds in my new draft on github for an example).=20 > > //foo.hh > class Foo { > *friend* Foo; > > }; > This again is putting an implementation detail (the fact that we will=20 reopen the class to implement it) in the interface. It seems unnecessary to= =20 me.=20 > > > =20 > =20 >> >> //Definition of Foo::pub1() >> void Foo::pub1() { >> _priv1(); >> _priv3(); >> } >> >> >> It is clear that all this would have less sense with modules. >> =20 > > Modules. Who knows what they are or when we will have them. I want=20 > something to solve my problems now. Also this can be a step towards modul= es. > =20 > You are right, but you will not have a new feature before 2017 as minor a= s=20 > it can be. > =20 Will we even have modules in 2017? There is no guarantee of that.=20 --=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_4365_21716991.1386743900243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wednesday, December 11, 2013 1:19:14 AM UTC-5, = Vicente J. Botet Escriba wrote:
=20 =20 =20
Le 11/12/13 03:55, fmatth...@gmail.com a =E9cr= it :
Wow lots of comments. 



I don't see any benefit to inline calls to private functions that would be defined in a .cc file as your
//Forward declaration of a private extension metho=
d
void Foo::_priv2();

//Inlined public method calls the private extension method
inline void Foo::pub2() { _priv2(); }


inlining the _priv2() call would result on th=
e same code.

I don't see neither the needed to declare new private functions on different files. Could you explain where this could be useful.

I've had plenty of situations where a class is implemented in multiple cc files in order to better separate concerns. I find myself doing this more for classes that implement "Application Logic." Usually singular concepts such as data structures are implemented in one cc file, if not entirely in the header due to templates.

In this situation, you would have your public header with the class definition, a private header with some extension method declarations, and finally multiple cc files with the definitions and possibly more file scoped extension methods as needed.
I understand your use case. Reducing compilation dependencies between implementation of different classes seems to me the problem to address. While taking care of the case where multiple files implements a specific class would be nice, it is for me a corner case. 

Reducing depende= ncies by minimizing the interface is the name of the game here. I agree tha= t multiple source files is a corner case, but I'd like to support it as it = is useful sometimes. 

Declaring an extension method in the same header as the class definition has little if no value. That's merely a stylistic choice. I included it just to show the possibilities.
So we agree this is not a must have.

Yes, but if you can declare a private extension method just like a = regular free function, there's no reason shouldn't be able to do it in the = class header. I suppose one corner use case is conditional compilation. One= version may want to call an inline PEM, while another does not (PEM is #if= defed out).
 


Maybe the idiom could be adapted to a language proposal that could avoid the cumbersome use of the that variable. It could consists in declaring a pseudo-struct declaration e.g. private Foo, that could contain only functions. These functions would be accessible only by the class Foo and any friend of Foo. Of course, in order to other classes to be able to use these private functions, the private pseudo-struct should be declared in another file.

//foo.hh
class Foo {
  public:
    Foo();
    void pub1();
    void pub2();
  private:

    int _i;
    int _j;
};

//foo.cc

private Foo {

  //Definition of _priv1()
  void _priv1() {
    /* function body */
  }

  //A new scoped private extension method.
  static void _priv3() {
    _i =3D 3;
  }

};
 
This is an interesting idea. Essentially reopening the scope to add more private stuff. Not only could you add new private methods but also private typedefs and nested classes as well. In the old thread (see github for the link), someone was essentially proposing this idea. He wanted to use a concept of class namespaces, but I like your syntax better.
Note that for me the scope could be reopened only once. In order to avoid that the user can do it on any class it would be better to restrict it to class that have declared it. E.g. we could declare the class friend of itself.

W= hy the restrictions? Can you demonstrate a case where allowing this feature= everywhere would cause a problem? How is this better than using a nested c= lass (see workarounds in my new draft on github for an example). 

//foo.hh
class Foo {
	friend Foo;
};
This again is putting an implementation d= etail (the fact that we will reopen the class to implement it) in the inter= face. It seems unnecessary to me. 





//Definition of Foo::pub1()
void Foo::pub1() {
  _priv1();
  _priv3();
}

It is clear that all this would have less sense with modules.

Modules. Who knows what they are or when we will have them. I want something to solve my problems now. Also this can be a step towards modules.
You are right, but you will not have a new feature before 2017 as minor as it can be.
 
Will we even have modules in 2017? The= re is no guarantee of that. 

--
 
---
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_4365_21716991.1386743900243-- .