220 7754 article Path: news.gmane.org!not-for-mail From: mitchnull@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Fixing the private method issue Date: Thu, 14 Nov 2013 05:59:16 -0800 (PST) Lines: 121 Approved: news@gmane.org Message-ID: References: <527a6d7d.ea42420a.1057.ffffdaad@mx.google.com> <7a8d898e-1884-49f7-b0c8-52af0813e6c4@isocpp.org> <6ed8056e-dbf9-427c-9aca-19af755b1801@isocpp.org> <8065ebf8-09e7-432d-b4bc-075ef8331a89@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_256_16224438.1384437557089" X-Trace: ger.gmane.org 1384437563 30960 80.91.229.3 (14 Nov 2013 13:59:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Nov 2013 13:59:23 +0000 (UTC) Cc: fmatthew5876@gmail.com, fmatthew5876@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC36XNFZ4YKBBN5OSOKAKGQEKZ4C3HY@isocpp.org Thu Nov 14 14:59:29 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VgxS4-0006lm-IE for gclcip-std-proposals@m.gmane.org; Thu, 14 Nov 2013 14:59:20 +0100 Original-Received: by mail-yh0-f70.google.com with SMTP id c41sf3877260yho.1 for ; Thu, 14 Nov 2013 05:59:19 -0800 (PST) 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=1If0qg2dCBBhIEk/OVIzKSCkdlQM3TcCSDdjFaxY1NI=; b=hqOyHM8/AX2HphQyYOFYCgXN3f2weCPMsktpUn1BH6QkHG/8BGbX75EHp82CKh70LR vJ9P8C8bj15VLJbXpPXb567AKO2yGwLU0YWFF8yaQmDIB8X3sMH8pnYT55eAlWvWQ99T pMdbY88JE3l6CqABowqEkkYTGX6KpAJPXfScBKSEbn9nAiMQ6OpW5n10tbVeKUpPr86K d9T5P+liNF1aT8tTmxYcy0gssWW050B/3UI9h/oBi+gjDvAYClf0KBYV5tmSK5Kgi1+E 5eExQ7iLofYxrWW/yaddThXtEl3AivvzoW4fj4SXBwAIiDhROTzQV2itABFqKxnWnSC/ sZpg== 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: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=1If0qg2dCBBhIEk/OVIzKSCkdlQM3TcCSDdjFaxY1NI=; b=APNw8PUeRcXpsjU4J9ps/d2Kif2zuW9CcdwKHTNC0GoYFNttKx5CoK1cCTE5EXxZ1q MTd9hR6I0PLl94OCmMniducum7EiJzPr5YZAJ4uZ4XwXkZ4cGfuqNtiz3xqaPN9MVyzh RiEXr/br4DD8syx/XFjK1rAYfeG+bswn8Pg/Iy/wTlqxLK+u57iS59f3sImbVPRx+2A0 3U/XfIPvHAQ8gJEFCmQK0OEPQAKXpzU1rmH4zjGz+g3f2TJTyb0gx4eCyKTSTzkMWq3J V8YAoGx9YRgHaDbEdWSFB+0Uic5GONYT1gbMoxCQns4wY9by5T3xbQEkcGEjbS2TJFTN Ae7A== X-Gm-Message-State: ALoCoQlGdRe8JGwV8wyk5oTf5p2eWHLxgqJ5pWVEC2CWUqkeq8jSbMVZulKhcodeBt+tPzHeYDJ5 X-Received: by 10.236.69.35 with SMTP id m23mr798436yhd.6.1384437559725; Thu, 14 Nov 2013 05:59:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.21.101 with SMTP id u5ls1398306ige.14.gmail; Thu, 14 Nov 2013 05:59:18 -0800 (PST) X-Received: by 10.50.73.99 with SMTP id k3mr38072igv.9.1384437558914; Thu, 14 Nov 2013 05:59:18 -0800 (PST) In-Reply-To: <8065ebf8-09e7-432d-b4bc-075ef8331a89@isocpp.org> X-Original-Sender: mitchnull@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:7754 Archived-At: ------=_Part_256_16224438.1384437557089 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, November 14, 2013 2:26:42 PM UTC+1, fmatth...@gmail.com wrote: [SNIP] > We can write 2 competing proposals. Either one I'd be happy with to > improve compile times and improve encapsulation by hiding more > implementation details from the user. > The original goal / scope of my (would be) class-namespace proposal is to allow writing the implementation of class members with a less verbose / more uniform (with regards to the declaration) syntax, shoehorning these hidden-private members into it doesn't seem like a good idea to me any more, so if anything solid comes out from this proposal, I'll address it in the class-namespace proposal, too, if appropriate, but I won't introduce this feature there. > > >> >> One issue that crossed my mind when thinking about "breaking" an existing >> class: it should not be possible to add a "hidden" private member that adds >> an overload to an existing declared private member. I don't know if >> there's a similar constraint elsewhere in the standard, or if it'd be >> completely new... >> > > I think its probably ok to do this. You can define overloads for normal > functions anywhere. Why not private member functions. The only taboo in my > mind is breaking encapsulation, which is what would happen if we allowed > extension of public, protected, data members, and/or virtual. > But you _can_ break encapsulation by introducing private overloads, consider this example: class Foo { int bar_; // ... int getBarImpl() const; public: int getBar() { return getBarImpl(); } }; // evil.cc: // non-const override of Foo::getBarImpl(): explicit int Foo::getBarImpl() { bar_ = 42; /* direct access to private member... */ } Foo f; f.getBar(); // calls our evil override getBarImpl() -- --- 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/. ------=_Part_256_16224438.1384437557089 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thursday, November 14, 2013 2:26:42 PM UTC+1, fmatth...= @gmail.com wrote:
[SNIP]
= We can write 2 competing proposals. Either one I'd be happy with to improve= compile times and improve encapsulation by hiding more implementation deta= ils from the user.

T= he original goal  / scope of my (would be) class-namespace proposal is= to allow writing the implementation of class members with a less verbose /= more uniform (with regards to the declaration) syntax, shoehorning these h= idden-private members into it doesn't seem like a good idea to me any more,= so if anything solid comes out from this proposal, I'll address it in the = class-namespace proposal, too, if appropriate, but I won't introduce this f= eature there.
 
 

One issue that crossed my mind wh= en thinking about "breaking" an existing class: it should not be possible t= o add a "hidden" private member that adds an overload to an existing declar= ed private member.  I don't know if there's a similar constraint elsew= here in the standard, or if it'd be completely new...

I think its probably ok to do this. You can define o= verloads for normal functions anywhere. Why not private member functions. T= he only taboo in my mind is breaking encapsulation, which is what would hap= pen if we allowed extension of public, protected, data members, and/or virt= ual. 

But you _can_ break = encapsulation by introducing private overloads, consider this example:

class Foo {
   int bar_;
   // ...
   int getBarImpl() const;
public:
   int getBar() { return getBarImpl(); }
};

// evil.cc:

// = non-const override of Foo::getBarImpl():
explicit int Foo::getBar= Impl() { bar_ =3D 42;  /* direct access to private member... */ }
Foo f;
f.getBar(); // calls our evil override getBarI= mpl()


--
 
---
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_256_16224438.1384437557089-- .