220 5891 article Path: news.gmane.org!not-for-mail From: nicolas.jinchereau@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Properties Syntax Date: Tue, 27 Aug 2013 12:46:12 -0700 (PDT) Lines: 171 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_2212_33335724.1377632772895" X-Trace: ger.gmane.org 1377632775 15156 80.91.229.3 (27 Aug 2013 19:46:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2013 19:46:15 +0000 (UTC) Cc: nicolas.jinchereau@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC42HSUOVYGBBBME6SIAKGQEQFCB3PI@isocpp.org Tue Aug 27 21:46:18 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f71.google.com ([209.85.216.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VEPDS-0004SG-R4 for gclcip-std-proposals@m.gmane.org; Tue, 27 Aug 2013 21:46:15 +0200 Original-Received: by mail-qa0-f71.google.com with SMTP id f14sf4404260qak.2 for ; Tue, 27 Aug 2013 12:46:14 -0700 (PDT) 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=tDw5YhntoJNwK9hn4kFJ37xi020tLsECbi0CgA0dmcM=; b=LEsDAO/DqDvHBjpymyiuWnHZOJVPQrtGcM1os8U+yX38bOYOjkAB1rGlZFa39dzGru xghqt8BrZ6L+I91yLbICRcNg7Gg4pgDoa6M+1CBW/7IENG5OOBXOrhWJZPJdKSdBQ/Sk wjGJ+peK7Wri4p/RQy2Sg6ZUmwinrW/4kmCFXNkSy4uepmhtCQCr9HtUiaGC42XqzSSo hn54X2gOx4t/NRNQLV+B7XBN96OlEJysZdq3ZNN+cELN4qGoceYA9PGBNRDHNeY5xkjl 3UcE/qgf8ZpKZFijG0HaPDoKAv7cnYflQRBEju6+XDrhbI6WFmXw5SAPByFf7uQEJ+X7 gijg== X-Received: by 10.236.227.165 with SMTP id d35mr4165107yhq.51.1377632773915; Tue, 27 Aug 2013 12:46:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.0.102 with SMTP id 6ls27924qed.34.gmail; Tue, 27 Aug 2013 12:46:13 -0700 (PDT) X-Received: by 10.49.70.170 with SMTP id n10mr96662qeu.22.1377632773383; Tue, 27 Aug 2013 12:46:13 -0700 (PDT) In-Reply-To: X-Original-Sender: nicolasjinchereau@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:5891 Archived-At: ------=_Part_2212_33335724.1377632772895 Content-Type: text/plain; charset=ISO-8859-1 First of all, I appreciate everyone taking the time to respond. However, I still stand by my suggested implementation of properties. Daniel, I do agree that there is a small chance for a mix-up, but any new language feature would introduce some kind of learning curve. Considering the current usage of const, virtual, default, and delete, I think that the relative complexity of a second usage of auto is very low, due to the fact that the current usage of 'auto' is very localized(used only in the place of a type). Also, I do agree that giving properties their own contextual keyword would be ideal, but considering that a new keyword may break existing code, I would favor using 'auto', because less conservative proposals for properties have already been rejected. Also, aside from the actual meaning of 'property' in Objective-C++ and CLI, there are many library based implementations(Like Richard's) which are called 'property'. Sean, Properties are meant to aid in encapsulation, and code readability. Reflection is unrelated to this issue. Saying that "C++ doesn't need properties" is like saying "C++ doesn't need lambda functions" or "C++ doesn't need range-based for loops", There are many cases where properties would allow for cleaner code that is easier to read, and easier to write. The case for properties has already been made. Java, C#, C++/CLI, Objective-C, and D all benefit from properties, and if C++ were to include them, a great many people would happily adopt them into their coding style. The amount of questions and library-based solutions you can find on Google should be more than enough to make that point. As far as why not to have properties: I am not suggesting the C# property syntax. (in response to your recent blog post) The method outlined in my original post does account for multiple return types, multiple parameter types, and cv-qualified functions through overloading. I have seen the argument about properties hiding complexity many times, and it's still wrong. In a managed language like C# or Java, I might be concerned about abusive use of complex properties, because of the way that the language is designed to be used, but I am sure that the C++ community could handle them just fine. And if someone was careless enough to be bitten by complex properties, I would be much more worried about them forgetting to call delete on their raw pointers, or trying to implement concurrency. Above all, the complexity is *not *hidden. All properties would be clearly marked as such in the header file, and provide the same guarantee about their complexity as would a function. And when the situation arose that a property was unusually complex, it could simply be omitted the same way that the standard omits the std::forward_list::size(). The declaration syntax I am suggesting also looks like a function, yet another clue about it's complexity. And for serialization, C++ properties would not provide any complication that doesn't already exist in a class with functions-properties. Richard, The library approach is already well known, and suffers from several problems: -memory usage -extra indirection -more complicated syntax -inability to use them in all cases that a variable would be allowed And even though your code is relatively clean, the compiler couldn't optimize it much without changing the observable size of the object. Please say say If I have failed to comment, or misinterpreted any of your concerns, Thanks -- --- 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_2212_33335724.1377632772895 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
First of all, I appreciate everyone taking the time to res= pond. However, I still stand by my suggested implementation of properties.<= div>

Daniel,

  I do agree = that there is a small chance for a mix-up, but any new language feature wou= ld introduce some kind of learning curve. Considering the current usage of = const, virtual, default, and delete, I think that the relative complexity o= f a second usage of auto is very low, due to the fact that the current usag= e of 'auto' is very localized(used only in the place of a type).
=
  Also, I do agree that giving properties their own con= textual keyword would be ideal, but considering that a new keyword may brea= k existing code, I would favor using 'auto', because less conservative prop= osals for properties have already been rejected. Also, aside from the actua= l meaning of 'property' in Objective-C++ and CLI, there are many library ba= sed implementations(Like Richard's) which are called 'property'.
=

Sean,

  Propert= ies are meant to aid in encapsulation, and code readability. Reflection is = unrelated to this issue.

  Saying that "C++ d= oesn't need properties" is like saying "C++ doesn't need lambda functions" = or "C++ doesn't need range-based for loops", There are many cases where pro= perties would allow for cleaner code that is easier to read, and easier to = write.

  The case for properties has already = been made. Java, C#, C++/CLI, Objective-C, and D all benefit from propertie= s, and  if C++ were to include them, a great many people would happily= adopt them into their coding style. The amount of questions and library-ba= sed solutions you can find on Google should be more than enough to make tha= t point.

As far as why not to have properties:

I am not suggesting the C# property syntax. (in respo= nse to your recent blog post)
The method outlined in my original = post does account for multiple return types, multiple parameter types, and = cv-qualified functions through overloading.

I have= seen the argument about properties hiding complexity many times, and it's = still wrong. In a managed language like C# or Java, I might be concerned ab= out abusive use of complex properties, because of the way that the language= is designed to be used, but I am sure that the C++ community could handle = them just fine. And if someone was careless enough to be bitten by complex = properties, I would be much more worried about them forgetting to call dele= te on their raw pointers, or trying to implement concurrency.
Above all, the complexity is not hidden. All p= roperties would be clearly marked as such in the header file, and provide t= he same guarantee about their complexity as would a function. And when the = situation arose that a property was unusually complex, it could simply be o= mitted the same way that the standard omits the std::forward_list::size(). = The declaration syntax I am suggesting also looks like a function, yet anot= her clue about it's complexity.

And for serializat= ion, C++ properties would not provide any complication that doesn't already= exist in a class with functions-properties.


<= /div>
Richard,

The library approach is already= well known, and suffers from several problems:
-memory usage
-extra indirection
-more complicated syntax
-ina= bility to use them in all cases that a variable would be allowed

And even though your code is relatively clean, the com= piler couldn't optimize it much without changing the observable size of the= object.



Please say = say If I have failed to comment, or misinterpreted any of your concerns,

  Thanks

--
 
---
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_2212_33335724.1377632772895-- .