220 8100 <52A803E2.6040203@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Private extension methods Date: Wed, 11 Dec 2013 07:19:14 +0100 Lines: 339 Approved: news@gmane.org Message-ID: <52A803E2.6040203@wanadoo.fr> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090704040105000503010704" X-Trace: ger.gmane.org 1386742750 16226 80.91.229.3 (11 Dec 2013 06:19:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Dec 2013 06:19:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBY4HUCKQKGQEUGZ4FQQ@isocpp.org Wed Dec 11 07:19:16 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-fa0-f71.google.com ([209.85.161.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vqd8e-0007oD-HR for gclcip-std-proposals@m.gmane.org; Wed, 11 Dec 2013 07:19:16 +0100 Original-Received: by mail-fa0-f71.google.com with SMTP id a11sf9033724fad.10 for ; Tue, 10 Dec 2013 22:19:16 -0800 (PST) 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=DBRiLe1tmx1wny7fIDzFawG9NyqN5MrRpLB7hjv7DvI=; b=HMPU+OVRrUilnYYTsO6DNUDa/RYmldbI3dJz+PLETCKcx8qMWCgjHV8N8hbMlBcZF8 mBnkses8k+Om1o11DiNAXs0PyYCA+jCKJE2N2psba/dzuJt/lOiLXZwh6D1NPpcKhfza L+Q8SSKHGxRoAnG0DHu9ZSPHXrepXP+2L8Y2Ip6DgEg5C+w7clnLt7DjIT9dO4SS4Zs8 NLr5yd07qzVmBBduhVrSgwu1IX8HpyJEoxHd0DK9z9y3JMvLG/rivFt2gkyjevZwTKcs Fjw+cgLip+XBFPtWHjc9CetvnaUja/uq5u6WRGlM/4wzpH0VpIAxGWuuIEwTXQTPK2j7 CMrQ== X-Gm-Message-State: ALoCoQk+Yx02RFZh+PeKKv7co6j3/kRMeNY0dDsT5KnA6akcLBKfNezkpALRtl8OMblE51viRdKn X-Received: by 10.14.115.72 with SMTP id d48mr14738508eeh.5.1386742756023; Tue, 10 Dec 2013 22:19:16 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.36.193 with SMTP id s1ls854612wij.16.canary; Tue, 10 Dec 2013 22:19:15 -0800 (PST) X-Received: by 10.194.192.233 with SMTP id hj9mr526091wjc.78.1386742755208; Tue, 10 Dec 2013 22:19:15 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr. [80.12.242.125]) by mx.google.com with ESMTP id gh6si2216061wic.41.2013.12.10.22.19.15 for ; Tue, 10 Dec 2013 22:19:15 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.125 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.125; Original-Received: from iMac-de-Vicente-Botet-Escriba.local ([92.139.147.80]) by mwinf5d57 with ME id 06KE1n00B1kJYz8036KEAb; Wed, 11 Dec 2013 07:19:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: <566b4320-4f64-4d14-ac61-6eb94c536967@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.125 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) 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:8100 Archived-At: This is a multi-part message in MIME format. --------------090704040105000503010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Le 11/12/13 03:55, fmatthew5876@gmail.com a =E9crit : > 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 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 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=20 > this more for classes that implement "Application Logic." Usually=20 > singular concepts such as data structures are implemented in one cc=20 > file, if not 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,=20 > and finally multiple cc files with the definitions and possibly more=20 > file scoped extension methods as needed. 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. > > Declaring an extension method in the same header as the class=20 > definition has little if no value. That's merely a stylistic choice. I=20 > included it just to show the possibilities. So we agree this is not a must have. > > > || > 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=20 > more private stuff. Not only could you add new private methods but=20 > also private typedefs and nested classes as well. In the old thread=20 > (see github for the link), someone was essentially proposing this=20 > idea. He wanted to use a concept of class namespaces, but I like your=20 > syntax better. Note that for me the scope could be reopened only once. In order to=20 avoid that the user can do it on any class it would be better to=20 restrict it to class that have declared it. E.g. we could declare the=20 class friend of itself. ||//foo.hh class Foo { *friend* Foo; || }; > > | > > //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=20 > something to solve my problems now. Also this can be a step towards=20 > modules. You are right, but you will not have a new feature before 2017 as minor=20 as it can be. 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/. --------------090704040105000503010704 Content-Type: text/html; charset=ISO-8859-1
Le 11/12/13 03:55, fmatthew5876@gmail.com a écrit :
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 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 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. 

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.
 


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 = 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.

//foo.hh
class Foo {
	friend Foo;
};





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

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