220 6038 article Path: news.gmane.org!not-for-mail From: Nick Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Properties Syntax Date: Fri, 30 Aug 2013 15:44:07 -0700 (PDT) Lines: 124 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_319_30777569.1377902648005" X-Trace: ger.gmane.org 1377902651 24195 80.91.229.3 (30 Aug 2013 22:44:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Aug 2013 22:44:11 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC42HSUOVYGBBOGAQSIQKGQEDKHXJRY@isocpp.org Sat Aug 31 00:44:10 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f200.google.com ([209.85.216.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VFXQH-0003rl-Px for gclcip-std-proposals@m.gmane.org; Sat, 31 Aug 2013 00:44:10 +0200 Original-Received: by mail-qc0-f200.google.com with SMTP id x12sf2409926qcv.11 for ; Fri, 30 Aug 2013 15:44:09 -0700 (PDT) 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=g4NV/SJJvelInmU4QMzXQ/fcRb3GF2OC1BYRGxLiano=; b=N+eoLkIaRZrBEK5FXLszxyyuLtFQitWaaHslHHTWYteVPKb7+jl53zHPmlN4kfeMfH sf/lumTvi1m8PmTjSI0kwKFyc77ZYvSpZyOsAJVFamUBzAQNypYrgI/SzYjT7RZesyJm iXtzi5PXaJlpBbaYaibcC22YevSY/Ct5/bW61WwpjwT/6caNHuW9ljkQFjdi5IpZUVq/ xKYKo84X3Yn0Y3e7mIaYmSDDPOZX9jLdVIXlLU2YZ1siZLPJv/GtXAZLuCtTyQyRMX3e MaYggSTTGPwdhy2kFJJQ0RhGj9daE4YEBGb9bvVeic9q3S+VI83C1RFZKSqxrsszJoQm O9Bg== X-Received: by 10.236.111.73 with SMTP id v49mr3975110yhg.46.1377902648913; Fri, 30 Aug 2013 15:44:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.85.4 with SMTP id d4ls1407441qez.76.gmail; Fri, 30 Aug 2013 15:44:08 -0700 (PDT) X-Received: by 10.49.28.97 with SMTP id a1mr462784qeh.0.1377902648499; Fri, 30 Aug 2013 15:44:08 -0700 (PDT) In-Reply-To: X-Original-Sender: nicolas.jinchereau@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:6038 Archived-At: ------=_Part_319_30777569.1377902648005 Content-Type: text/plain; charset=ISO-8859-1 *I would not even want to think about having a PMP which packetizes the getter and all setters into an "overloaded member function pointer"* This would not have to be the case, but I understand how it may seem that way. For that reason, *I should revise my original premise.* At this point, I don't even believe this concept should be referred to as properties. I believe the wording from N1611 is much more appropriate. I do not believe the word "Property" should be associated with this concept at all, because questions like the one I have quoted above will just keep coming up. I believe this issue should be labelled both in terminology, and in the C++ language as "implicitly callable functions". It should be clearly labelled as a language construct specific to C++, which has no explicit or implicit relationship to "properties" in any other language. And the contextual keyword "implicit" should be used to denote that a class member function can be implicitly called. These functions could be described as functions that are called implicitly as needed to facilitate the usage of an appropriately qualified identifier, where the get and set methods may be called one or more times in a single expression. With the above revision in mind, the response to the original concern about function pointers becomes obvious: T(Class::*)() != void(Class::*)(T) *"Nick: In the same situation, what happens when the code evolves is that the address of the member goes from being a T* to a T (CLASS::*)(), which is rather a big difference."* That is true, and yet another reason why I feel it's necessary to revise my original premise. I believe making it known that these are functions would allow the caller to make better judgement concerning their use. *"void f(int &i) { i = 2; } * *Whereas before you could call this indirect setter, with properties you can't."* This is also true, along with many similar cases, and it may make sense to create a list of attributes of regular functions that would be prohibited in the case of implicitly callable functions. I don't believe that placing a few restrictions on unnecessary use cases would hurt the overall usefulness of properties. -- --- 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_319_30777569.1377902648005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would not even want to think about having a PMP = which packetizes the getter and all setters into an "overloaded member func= tion pointer"

This would not have to be the ca= se, but I understand how it may seem that way. For that reason, I should= revise my original premise.

At this point, I = don't even believe this concept should be referred to as properties. I beli= eve the wording from N1611 is much more appropriate. I do not believe the w= ord "Property" should be associated with this concept at all, because quest= ions like the one I have quoted above will just keep coming up. I believe t= his issue should be labelled both in terminology, and in the C++ language a= s "implicitly callable functions". It should be clearly labelled as a langu= age construct specific to C++, which has no explicit or implicit relationsh= ip to "properties" in any other language. And the contextual keyword "impli= cit" should be used to denote that a class member function can be implicitl= y called. These functions could be described as functions that are called i= mplicitly as needed to facilitate the usage of an appropriately qualified i= dentifier, where the get and set methods may be called one or more times in= a single expression.

With the above revision in m= ind, the response to the original concern about function pointers becomes o= bvious:

T(Class::*)() !=3D void(Class<= /span>::*)(T)


"Nick: In the same situation,= what happens when the code evolves is that the address of the member goes = from being a T* to a T (CLASS::*)(), which is rather a big difference."=

That is true, and yet another reason why I feel i= t's necessary to revise my original premise. I believe making it known that= these are functions would allow the caller to make better judgement concer= ning their use.

"void f(int &i) { i =3D 2; = } 
Whereas before you could call this indirect setter= , with properties you can't."

This is also tru= e, along with many similar cases, and it may make sense to create a list of= attributes of regular functions that would be prohibited in the case of im= plicitly callable functions. I don't believe that placing a few restriction= s on unnecessary use cases would hurt the overall usefulness of properties.=

--
 
---
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_319_30777569.1377902648005-- .