Abstract (tl;dr)
Please read the full question, this is awfully simplified:
How can unix file permission style restrictions be applied to inter-type data/control flows, allowing fine-grained access to some class-members for some groups of classes?
Background information
If you think about unix file systems and permissions, there is a diverse way of encoding file-access privileges of users (especially if you also consider FACL). For example, if a directory contains 3 files, they could belong to several users, and different other users may have restricted permissions:
-rwxr-xr-- jean-luc staff engage.sh
-rw-r----- william crew roster.txt
-rw------- beverly beverly patients.txt
Core idea
As you can see, depending on the groups a particular user is in, different access levels are allowed. For example, crew
members are allowed to read roster.txt
, which belongs to william
, but guests who presumably do not belong to crew
cannot. More importantly, the group crew
can contain many people.
So I was thinking that there is some similarity to access permissions inside object oriented languages like C++ if you think of types (classes) as users. Although a function can only be executed, but not read, the rwx
flags represent meaningful descriptions for class members. A data member can be read (r
) and written (w
) to, perhaps via accessors, while member functions may be executed (x
) or not.
However, in C++ and other object oriented languages (I know of), this is more or less an all or nothing thing, if we leave out inheritance for a second; If class William
makes his member Txt roster;
public, everybody will see it. If he makes it private, nobody except himself will see it. He may add one or more friends, friend JeanLuc;
but then they will see all his private members (the equivalent of granting user:jean-luc:rwx
to all his files, in FACL lingo).
This is entirely orthogonal to inheritance -- JeanLuc
and William
are not part of the same hierarchy, they are not related.
So the main idea would be to allow group-based access restrictions, as a generalisation of private/public. Allowing finer grained inter-class access to member functions and member data.
I believe this idiom could help maintainability/readability, as it adds additional facets to restrict interaction permissions. As with operating systems, where this adds an important layer of security to the system, the same familiar pattern could add safety to a C++ project.
Thoughts about representation in C++
However, I'm at a loss of thinking of a good way to represent this. You could decompose William
objects into several objects of subtypes: William_Crew
, William_William
and so forth, representing the respective groups. This seems to be horribly ugly. Another idea could be dedicated types with forwarder functions, representing the individual groups, like this:
class Crew { // group class
// in this group are:
friend JeanLuc;
friend Geordi;
friend Beverly;
// ...
static Txt getRoster(William*);
};
class William {
friend Crew; // Problem: Crew has full access (rwx)
Txt roster;
};
But each group would have to be tailored to a particular class to be used with, which would seem to be massively redundant, if the group is used by several users/classes.
Question
The approaches I provided are not great (to put it mildly), and I'm sure they wouldn't work as intended. I'm not sure if this is a novel/stupid/well-known idea, but I wonder how you could implement this with the features provided by the C++ language. Are there objective arguments why this would or would not be useful/helpful?