220 19942 article Path: news.gmane.org!not-for-mail From: Arthur Tchaikovsky Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default arguments Date: Thu, 20 Aug 2015 02:20:31 -0700 (PDT) Lines: 175 Approved: news@gmane.org Message-ID: References: <89bf9d09-00ed-45db-bf88-39c844707bd1@isocpp.org> <87b15f40-b36a-47bd-b822-8df53dd72287@isocpp.org> <55D4CD4A.8070803@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_127_782561607.1440062431912" X-Trace: ger.gmane.org 1440062444 10866 80.91.229.3 (20 Aug 2015 09:20:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Aug 2015 09:20:44 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDL6FI4NYYERBYNX22XAKGQERSVPH5I@isocpp.org Thu Aug 20 11:20:44 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZSM1S-0003d5-T3 for gclcip-std-proposals@m.gmane.org; Thu, 20 Aug 2015 11:20:35 +0200 Original-Received: by paom9 with SMTP id m9sf5494972pao.0 for ; Thu, 20 Aug 2015 02:20:34 -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 :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=WUFFc9WaYjppZQdiGxlVATbtTzzpoZcPssyyCwbR8uM=; b=G75ZtXY62HsjVBBAe89n/bWqtRBBnW86rubSvORDSZ6oN5HxNJe7eK/rK6szoYm7XR DoOKybBoXta0YBlbWsX4Z2r9CwTelbv9CAmYoimWgI/10AV9hfohOZJ6Jyr2EBpKncWk rvpKNRjVDBRRe3stYTm6jMHv/0SZLhW5XtYXFLrvFTk5zBG5LiCUkBTmlmAhpYrDv5Ig I9f5ycRQR/fYQ3scvGMmrJ2adR54kW9TCBxmEN4g9gm13xCtVm/LjkeaCOe2zjcBD+5n bzdtV1Bjlca3GCMrbQLCkY8KkwyRT/5haUI7ndDG1VSFyatr6IrSCynm5qvrmFrbXA3e hPVA== 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:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=WUFFc9WaYjppZQdiGxlVATbtTzzpoZcPssyyCwbR8uM=; b=Kaj6XD1JXuBqQa7nAq9+fG0CwvZ0f23FuCi45B/zHpWieoDGKHkeNsBmQ9YPLvbx2K zJLQck+ooLc1aHSxmwhZqBRY4zSyi6WHhpFtAzgzeEkM0ny8y1XHSi0WOsFgTiboQZ+N X2Bz7A4Lww4D8nOiYeBx2RjL0glArS7Z8ad1DiqMONI2fACdJS5XWVPcG3sITzOsQAeM p3P9a34ZmbVn21ICFpsb4rtqvPMIyfs11GnDIgmzSDTA6/CiKKhxuIxzdshWsYtK6ipJ +bC7iF0Gg3ftsfIPPhaPNW5yrjWnDhoELFmriY/Nex/8KbqDVcmh8mgAaJ2UVIlY7RN2 tp3Q== X-Gm-Message-State: ALoCoQkDVEsIglWLnzoC34oXdfdcYrSYlIrzPvgjE25TCtJuTcEKA6czYaEh6K9PNlT4lw6p2Lt5 X-Received: by 10.66.140.101 with SMTP id rf5mr1573579pab.14.1440062433930; Thu, 20 Aug 2015 02:20:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.34.134 with SMTP id l6ls53010qgl.13.gmail; Thu, 20 Aug 2015 02:20:32 -0700 (PDT) X-Received: by 10.140.23.50 with SMTP id 47mr18602qgo.24.1440062432841; Thu, 20 Aug 2015 02:20:32 -0700 (PDT) In-Reply-To: <55D4CD4A.8070803@gmail.com> X-Original-Sender: atch.cpp@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:19942 Archived-At: ------=_Part_127_782561607.1440062431912 Content-Type: multipart/alternative; boundary="----=_Part_128_2034979186.1440062431912" ------=_Part_128_2034979186.1440062431912 Content-Type: text/plain; charset=UTF-8 First, I want to say that I don't mind harsh, not harsh, too harsh words as long as their valid and I welcome any *valid* criticism and I consider your input very, very valid. No problem with that and I will not get offended by such thing. OK, let's go back to the business, point by point. Andrey, you're saying that you don't see connection between default access mode and encapsulation. Could you please give an example or two, so we can see how that reflects reality? Because at this moment I'm having hard time to accept it, given that we're talking about the same thing. OK, second point. You're saying and I quote: "And no, all-public structs do not violate encapsulation in general. For instance, std::pair - a struct with public data, does not break encapsulation of std::(unordered_)map. " Again, why would unrelated type break encapsulation of other type? I really don't see connection, in the same way I don't expect a container of ints to automatically provide ++, -- and other operators. And also please note that std::pair **do not** provide encapsulation. Because you can access it's members. OK, so you're asking me, what's my point then? My point is that I do understand the fact that OOP is not the only technique we should use during programming, but I **do not agree** with introduction of rules to the C++ language that would allow to *bypass* that encapsulation. Thank you. On Wednesday, 19 August 2015 19:39:10 UTC+1, Andrey Semashev wrote: > > On 19.08.2015 21:07, Arthur Tchaikovsky wrote: > > Not all members in struct are public. From elementary school, everyone > > knows that struct differs from class that *by default* members are > > public in struct and private in class. ;) > > That's why I see it as a violation of encapsulation. > > I don't see the connection between the default access mode and > encapsulation. Encapsulation is implementation hiding. It can be > achieved by different means, including but not limited to member access > management. Classes are no different from structs except for the default > access mode - both can be used to achieve the same level of encapsulation. > > And no, all-public structs do not violate encapsulation in general. For > instance, std::pair - a struct with public data, does not break > encapsulation of std::(unordered_)map. > > > Secondly, not only > > structs should be concerned, but classes too. And not only > > initialization should be a concern here but also setting value *after* > > the object had been initialized. Taken all this above, I say that > > accessing members of a class/struct by names, be it during > > initialization or after that fact is violation of encapsulation and it > > should be discouraged in modern C++. This kind of code may very well be > > OK for C but C++ is not C. > > I don't mean to sound harsh, but that's narrow minded thinking. The 'OOP > everywhere' era has passed as people realized that it is not efficient > in all scenarios. C-style structs are useful in some contexts and named > member initialization is useful as well. See ffmpeg code for instance, > the way codecs and formats are described. That's C, naturally, but > imagine how much more code that would require in today's C++ with > private members, constructors and default arguments. And then imagine > how difficult it would be to modify the struct used as the descriptor. > > -- --- 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_128_2034979186.1440062431912 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, I want to say that I don't mind harsh, not hars= h, too harsh words as long as their valid and I welcome any *valid* critici= sm and I consider your input very, very valid. No problem with that and I w= ill not get offended by such thing. OK, let's go back to the business, = point by point.
Andrey, you're saying that you don't see connec= tion between default access mode and encapsulation. Could you please give a= n example or two, so we can see how that reflects reality? Because at this = moment I'm having hard time to accept it, given that we're talking = about the same thing.
OK, second point. You're saying and I quote:"And no, all-public structs do not violate encapsulation in general.= For=20
instance, std::pair - a struct with public data, does not break=20
encapsulation of std::(unordered_)map. "
Again, why would unrelated type break encapsulation of other type= ? I really don't see connection, in the same way I don't expect a c= ontainer of ints to automatically provide ++, -- and other operators. And a= lso please note that std::pair **do not** provide encapsulation. Because yo= u can access it's members.

OK, so you're asking me, what'= ;s my point then? My point is that I do understand the fact that OOP is not= the only technique we should use during programming, but I **do not agree*= * with introduction of rules to the C++ language that would allow to *bypas= s* that encapsulation.
Thank you.

On Wednesday, 19 August 2015 19= :39:10 UTC+1, Andrey Semashev wrote:
On 19.08.2015 21:07, Arthur Tchaikovsky wrote:
> Not all members in struct are public. From elementary school, ever= yone
> knows that struct differs from class that *by default* members are
> public in struct and private in class. ;)
> That's why I see it as a violation of encapsulation.

I don't see the connection between the default access mode and=20
encapsulation. Encapsulation is implementation hiding. It can be=20
achieved by different means, including but not limited to member access= =20
management. Classes are no different from structs except for the defaul= t=20
access mode - both can be used to achieve the same level of encapsulati= on.

And no, all-public structs do not violate encapsulation in general. For= =20
instance, std::pair - a struct with public data, does not break=20
encapsulation of std::(unordered_)map.

> Secondly, not only
> structs should be concerned, but classes too. And not only
> initialization should be a concern here but also setting value *af= ter*
> the object had been initialized. Taken all this above, I say that
> accessing members of a class/struct by names, be it during
> initialization or after that fact is violation of encapsulation an= d it
> should be discouraged in modern C++. This kind of code may very we= ll be
> OK for C but C++ is not C.

I don't mean to sound harsh, but that's narrow minded thinking.= The 'OOP=20
everywhere' era has passed as people realized that it is not effici= ent=20
in all scenarios. C-style structs are useful in some contexts and named= =20
member initialization is useful as well. See ffmpeg code for instance,= =20
the way codecs and formats are described. That's C, naturally, but= =20
imagine how much more code that would require in today's C++ with= =20
private members, constructors and default arguments. And then imagine= =20
how difficult it would be to modify the struct used as the descriptor.

--

---
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>.
------=_Part_128_2034979186.1440062431912-- ------=_Part_127_782561607.1440062431912-- .