   ideia for a c++ proposal: channels
  Hi ppl.I have got a c++ idea, I think is a new ideia and I want to share with you for discussion.The thing is, I had a discussion with a team mate of mine about the uses of friends in classes. He sayed that friends are just evil, but, I can use them for good things, inclusively, to encapsulate data (belive me or not, friends can encapsulate data).The ideia to encapsulate with friends comes as follows:Class Manager {private:   list of Objects;};class Object {public:   Object(Manager* manager);};Object can only exist if inserted into a Manager of Objects, so, clients must create an Object giving the manager. The problem here is that objects can only insert itself into it's manager using public functions on Manager, something that should be private in the Manager. It happens that the client gets full access to the inner workings of Manager.Using friends in this case, opens a channel between the Manager and Object. Object can insert itself into Manager using the private functions from Manager and the client has no access to the inner workings of managging.Althow, there is a problem here: Manager gives to much to the Object.My solution is the following:class Manager {public:   ...pritected:   ...private:   list of Objects;channel Object:   void InsertNewObject(Object* obj);};class Object {public:   Object(Manager* manager);};In this case, Manager would give a special interface to Object and only public and channel parts of Manager are visible to Object, protected and private are still hidden. For clients, only the public, and not channel parts, are visible.Is this a valid proposal for the C++ Core? Or there are any problem here that I cannot see?   
  While it might have advantages I'm missing, it would seem not. By changing the design slightly (making the manager a factory), you solve pretty much all of your example's problems without the need to change the language (or resort to friend).   ;  Why must the object insert itself into the manager?I would let the manager take care of that.PSEUDOCODE:function manager::createObject() {object = new Object();this.insertIntoList(object);return object;}The Object does not know about the manager.You could even make the Object constructor private and make Managera friend of object so only the manager can create objects.cheers   ;  Having Object responsible for automatically inserting itself into Manager's list violates the Single Responsibility Principle. It's also a bad idea.As for your proposal: You can already do this. Simply have the class implement an interface with the required methods, and pass a pointer to the interface instead of the class.   ;  The C++ language committee is extremely conservative about what it adds.  It won't add this, because there are other ways of doing it.   ;Quote:Original post by Filamibelive me or not, friends can encapsulate data).Code can be written with complete and total encapsulation in C, even in assembly.Languages which support visibility scope just add additional safety checks - but they are not what enables it. As it happens, many solid libraries written in C provide surprising encapsulation and often act as completely opaque.friend access breaks encapsulation no more than private provides it. Same reasoning can be applied to reflection in managed languages.There are two problems with presented approach:- friend keyword already does this- channel implies something very differentAnd since this is C++, there's likely hundreds of pitfalls lurking after considering inheritance, namespaces, scopes, virtual functions, templates, pre-processor and who knows what else.;  Also, friends aren't bad.  You shouldn't be sprinkling them around everywhere, and a manager and object class probably shouldn't be friended, but there are plenty of legit uses for friend.   ;Quote:Original post by NumsgilThe C++ language committee is extremely conservative about what it adds.  It won't add this, because there are other ways of doing it.Really? C++ is one of the largest languages around, and it is only getting bigger if they ever release C++0x. Although I agree they wouldn't add something like this.   ;  Guess the ideia is not very popular. I thought it to be interesting and easy to implement in the core of a language, but ok.At least, you are in the same opinion that friends actualy have uses and can be very usefull in many situations. Some team mates of mine are just mindless saying that friends are bad and should not be used.   ;  Like all things, friend is a tool that can be used properly or improperly. Just like goto or any number of other "controversial" techniques or keywords.Now, friend is not something you want to be your go-to tool. The keyword 'friend' expresses the second-most powerful relationship there is in C++, second only to inheritence. most powerful relationship there is in C++, even more powerful than inheritence. Like all tools, the more powerful and far-reaching the potential effects are, the more reservation you should have in reaching for it, and the more carefully it should be applied.When you want to butter your bread, you don't reach for a 12-inch chef's knife (or worse), you reach for a butter knife. Why? Common sense teaches us (most of us, anyway... ) to use the tool which does the job aptly with the lease potential for something to go horribly wrong.Applied to C++, the analog to this common-sense practice is to use the least-powerful construct which satisfies the requirements of the task -- really, that is probably one of the most fundamental tenets of software engineering, or more accurately, of all engineering and which applies even more broadly than that.UPDATE: Edited to correct a misquote.[Edited by - Ravyne on August 27, 2008 1:39:03 PM]