220 10935 article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Protect Lambda functions against reflection Date: Wed, 28 May 2014 23:57:00 +0200 Lines: 104 Approved: news@gmane.org Message-ID: References: <108c47a2-d952-4f84-a347-923b2ab742ad@isocpp.org> <7ef3d3da-0c1d-443c-88d2-656b91937170@isocpp.org> <68f98b78-8bd4-48e0-9e1d-47cfc0492764@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec50e5ea555bd9304fa7ce4be X-Trace: ger.gmane.org 1401314230 21636 80.91.229.3 (28 May 2014 21:57:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 May 2014 21:57:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBLNXTGOAKGQEICPOJDI@isocpp.org Wed May 28 23:57:03 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f71.google.com ([209.85.219.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WplqJ-0006OO-3h for gclcip-std-proposals@m.gmane.org; Wed, 28 May 2014 23:57:03 +0200 Original-Received: by mail-oa0-f71.google.com with SMTP id m1sf58955894oag.10 for ; Wed, 28 May 2014 14:57:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from: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=khhn2eK/a0UhvI2t2ASqSXOgADilmUqe3bBkWpKgZ+0=; b=cg6x8OW686DEbarNagC21HytqkZjlrMUADaTNFP7ae+svyqAKiJeFYQJG7wcYZrJe/ tN+n2Pol4CwndkOCNooJgvoneomSwvA6fJzw5ttfQnnFSucnJhRWSKd7aOd67WaCdIVW 2DauUVjBt3iY5H95y0BsjmOe0A6JI8hG7z6P/BqN0RLj2dGFE81s9qdJ074QPrTMtLjG KTjPjoBBVCg76agXolprm06duZ0JnhHfEiNkEt1jPuGzgJTdk657NrBxRTjwM39+0lSM v2gwnv3UIULCkn6n+ypn35bkLn/dFIprhjiLUB2p4XrGvcuG3HzFBZgUmJmcVEWw/rg8 YllA== X-Gm-Message-State: ALoCoQlY7Zk8GFUnNTB5mdBUbtTjlE64Wmb3aBt5SteSCDuLsqXo/7yrrAoKJXZuoki/uOk2YjKJ X-Received: by 10.42.10.141 with SMTP id q13mr1086057icq.5.1401314221851; Wed, 28 May 2014 14:57:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.73.229 with SMTP id o5ls3031358igv.21.canary; Wed, 28 May 2014 14:57:00 -0700 (PDT) X-Received: by 10.50.43.136 with SMTP id w8mr5227392igl.20.1401314220773; Wed, 28 May 2014 14:57:00 -0700 (PDT) Original-Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [2607:f8b0:4001:c05::22b]) by mx.google.com with ESMTPS id o13si15517884igw.42.2014.05.28.14.57.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 14:57:00 -0700 (PDT) Received-SPF: pass (google.com: domain of andrewtomazos@gmail.com designates 2607:f8b0:4001:c05::22b as permitted sender) client-ip=2607:f8b0:4001:c05::22b; Original-Received: by mail-ig0-f171.google.com with SMTP id c1so3020488igq.10 for ; Wed, 28 May 2014 14:57:00 -0700 (PDT) X-Received: by 10.42.253.130 with SMTP id na2mr2797383icb.82.1401314220553; Wed, 28 May 2014 14:57:00 -0700 (PDT) Original-Received: by 10.64.7.179 with HTTP; Wed, 28 May 2014 14:57:00 -0700 (PDT) In-Reply-To: X-Original-Sender: andrewtomazos@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of andrewtomazos@gmail.com designates 2607:f8b0:4001:c05::22b as permitted sender) smtp.mail=andrewtomazos@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:10935 Archived-At: --bcaec50e5ea555bd9304fa7ce4be Content-Type: text/plain; charset=UTF-8 On Wed, May 28, 2014 at 11:17 PM, Nevin Liber wrote: > - they're there to prevent accidental misuse, > > Relying on an implementation detail is misuse, because the class author > has not promised to either maintain that implementation or fix the external > things dependent on the implementation. By, say, granting friendship, the > author is making that promise. > It's quite difficult relative to normal member access to use the reflection mechanism to access a specific member of a specific class. It's designed to write code that accesses all members of any class in a uniform way, and performs some sort of aggregate operation. As such, this access is generally a "cross-cutting concern" so when those implementation details change, the reflection application changes along with them in an expected way. The reflection application isn't dependent or brittle on the specific details. Take for example a debugger that shows the names and values of private data members. You wouldn't say the debugger is dependant on the details of those private data members. If private members are added, changed or deleted - the debugger continues to work, it just shows the new names and values automatically. Now, if some nitwit jumps cartwheels to use the reflection mechanism to access and depend on a specific private member of a specific class that he couldn't get access to with normal member access, the class author changes that member, and said nitwits code breaks. I would say that is the nitwits fault and not the class designers. Furthermore, I don't think adding some boilerplate "friend reflection" line to all class specifiers changes that analysis or blame assignment. -- --- 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/. --bcaec50e5ea555bd9304fa7ce4be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 28, 2014 at 11:17 PM, Nevin Liber <nevin= @eviloverlord.com> wrote:
- they're there to prev= ent accidental misuse,

Relying on an implementation detail is misuse, because the class author has= not promised to either maintain that implementation or fix the external th= ings dependent on the implementation. =C2=A0By, say, granting friendship, t= he author is making that promise.
=C2=A0
It's quite dif= ficult relative to normal member access to use the reflection mechanism to = access a specific member of a specific class.=C2=A0 It's designed to wr= ite code that accesses all members of any class in a uniform way, and perfo= rms some sort of aggregate operation.=C2=A0 As such, this access is general= ly a "cross-cutting concern" so when those implementation details= change, the reflection application changes along with them in an expected = way.=C2=A0 The reflection application isn't dependent or brittle on the= specific details.

Take for example a debugger that shows the names and values = of private data members.=C2=A0 You wouldn't say the debugger is dependa= nt on the details of those private data members.=C2=A0 If private members a= re added, changed or deleted - the debugger continues to work, it just show= s the new names and values automatically.

Now, if some nitwit jumps cartwheels to use the reflection m= echanism to access and depend on a specific private member of a specific cl= ass that he couldn't get access to with normal member access, the class= author changes that member, and said nitwits code breaks.=C2=A0 I would sa= y that is the nitwits fault and not the class designers.

Furthermore, I don't think adding some boiler= plate "friend reflection" line to all class specifiers changes th= at analysis or blame assignment.

--

---
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-proposa= ls+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>.
--bcaec50e5ea555bd9304fa7ce4be-- .