220 6021 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Properties Syntax Date: Fri, 30 Aug 2013 18:12:33 +0200 Lines: 112 Approved: news@gmane.org Message-ID: References: <5e23a0e9-2bd9-4f62-aa83-47bea8144eae@isocpp.org> <521DAAF4.3050100@beamways.com> <521DE3EC.4040404@beamways.com> <521E8AB0.6070906@numericable.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e012953ba840c3904e52c7d09 X-Trace: ger.gmane.org 1377879154 1920 80.91.229.3 (30 Aug 2013 16:12:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Aug 2013 16:12:34 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD3NR2WQQ4IBB4UIQOIQKGQE2CM3BNQ@isocpp.org Fri Aug 30 18:12:37 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VFRJL-0004lu-Jg for gclcip-std-proposals@m.gmane.org; Fri, 30 Aug 2013 18:12:35 +0200 Original-Received: by mail-ob0-f199.google.com with SMTP id dn14sf7692920obc.6 for ; Fri, 30 Aug 2013 09:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=OOLjYE8GFFDc5zaCfGmoIONxZGYzuO/pUJ3xm5RZm1A=; b=0x6O3i/KiuXAJMCpkcI6XQgHpiJtpKzpj5/nlWxV5dzV6M59vlkrgOiPM+FZeSKvuY ku9JPFE96vz6M5DohmHjIVTJzJZMAYwCAWiRUz3GfXQRUN2nZCJ4a7HgN4AFF442MHxN nTBwnqnhcAv9LN+NVIT+eq0IXvK22Qhm9PuNA4ytg/Vc7wypLSO3LPanqt8IfurHHLgP kUwu6pG0aMZVo849xwklpWAkB/jSbVWZv/NJv6l71P/GSlqwFPmwdcTqNkaYRKECmGFP wThqlH7bCJ13o9e/riIiJKZjwH0OJu159Iqp1t66uhaLE4RKUpWoH85xxPu8sDFKlJr6 881g== X-Received: by 10.182.105.227 with SMTP id gp3mr2387633obb.23.1377879154505; Fri, 30 Aug 2013 09:12:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.85.138 with SMTP id h10ls250671obz.74.gmail; Fri, 30 Aug 2013 09:12:34 -0700 (PDT) X-Received: by 10.60.116.170 with SMTP id jx10mr473990oeb.98.1377879154104; Fri, 30 Aug 2013 09:12:34 -0700 (PDT) Original-Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [2607:f8b0:4003:c01::22a]) by mx.google.com with ESMTPS id i3si5616740obz.81.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 09:12:34 -0700 (PDT) Received-SPF: pass (google.com: domain of mjklaim@gmail.com designates 2607:f8b0:4003:c01::22a as permitted sender) client-ip=2607:f8b0:4003:c01::22a; Original-Received: by mail-ob0-f170.google.com with SMTP id eh20so2109802obb.29 for ; Fri, 30 Aug 2013 09:12:34 -0700 (PDT) X-Received: by 10.60.62.4 with SMTP id u4mr7460243oer.35.1377879153967; Fri, 30 Aug 2013 09:12:33 -0700 (PDT) Original-Received: by 10.76.27.194 with HTTP; Fri, 30 Aug 2013 09:12:33 -0700 (PDT) In-Reply-To: X-Original-Sender: mjklaim@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mjklaim@gmail.com designates 2607:f8b0:4003:c01::22a as permitted sender) smtp.mail=mjklaim@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) d=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:6021 Archived-At: --089e012953ba840c3904e52c7d09 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 30, 2013 at 6:05 PM, Nevin Liber wrote: > I find this uncompelling, because such transformations can easily break > correctness. If someone expects the call to count() to return the same > value in two successive calls (which might not even be in the same > function), this transformation breaks them. > > I believe you are making the same point than Martinho Fernandes so I should have answered in my last email. > In practical terms, I've found it incredibly rare to make these kind of > wholesale changes to implementations (those that change preconditions or > postconditions) without having to revisit the entire program. > > It depends on the requirements but I also find rare a change of requirements by changing implementation of a function. However, I don't always have checks that make sure I didn't change these requirements. To me all these points are about the requirements part of any kind of function (properties included) which indeed are hard to prove not being changed by a change of the implementation. But again, fixing that requires another set of language feature and is not directly related to properties, in my opinion. > > What problem is trying to be solved with properties? Is it just the > syntactical notation of not having to use parentheses? > More or less. I belive the point of properties to be about allowing both member object and member functions to be used in the same way so that one could be upgraded to the other when the need come, without having to modify the whole code base. -- --- 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/. --089e012953ba840c3904e52c7d09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Fri, Aug 30, 2013 at 6:05 PM, Nevin Liber <nevin@eviloverlord.com= > wrote:
I find this uncompelling, because such transformation= s can easily break correctness.=A0 If someone expects the call to count() t= o return the same value in two successive calls (which might not even be in= the same function), this transformation breaks them.


I believe you are making the sam= e point than=A0Martinho Fernandes so I should have answered in my last emai= l.
=A0
In practical terms, I've found it incredibly rare to ma= ke these kind of wholesale changes to implementations (those that change pr= econditions or postconditions) without having to revisit the entire program= ..


It depends on the requirements b= ut I also find rare a change of requirements by changing implementation of = a function.
However, I don't always have checks that make sure I did= n't change these requirements.
To me all these points are about the requirements part of any kind of funct= ion (properties included) which indeed are hard to prove not being changed = by a change of the implementation.
But again, fixing that requires anoth= er set of language feature and is not directly related to properties, in my= opinion.
=A0

What problem is trying t= o be solved with properties?=A0 Is it just the syntactical notation of not = having to use parentheses?

More or less. I belive the point of properties to be= about allowing both member object and member functions to be used in the s= ame way
so that one could be upgraded to the other when the need come, w= ithout having to modify the whole code base.

--
 
---
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>.
--089e012953ba840c3904e52c7d09-- .