Re: Why no access specifiers for friends?
Lourens Veen wrote:
kanze wrote:
The first remark was really about the fact that control is
on a class basis. Be it friendship or the fact of being a
member functions, access is granted automatically to the
entire class, and not to parts of it. And there are times
when one would like to be more restrictive.
So then apparently there is a subset of the class members that
forms some sort of logical unit. Shouldn't that be a separate
(or perhaps inner) class then?
Maybe. I don't recall the exact cases where I had this
impression, and it's quite possible that your solution could
have applied to them (and might have been cleaner).
In the end, it boils down to my basic point concerning finer
granularity: how much extra complexity is it worth. In all
cases, the friend was part of the implementation; I controled it
just as much as I controled member functions. So a simple
implementation comment as to what it might change seemed
sufficient. Anything more would have been more complexity than
it was worth.
Why can we not simply conclude
in that case that the granularity of the classes isn't small
enough? Can you give an example?
In the end, one can imagine many different levels of access: in
large applications, it is not unusually to define any number of
different "roles", to assign each user to one or more roles, and
each role to a different set of rights (access or modification).
And it's not unusual to want something more or less along these
lines for a class. The question is simple: how much extra
complexity would it entail, and is it worth it? For the moment,
I've not seen any concrete proposals to judge, but my impression
is that would introduce a lot of extra complexity. And that
given the relatively small size of classes, the benefits would
be minor.
Again, I don't really see the problem. Can't we just define a
bunch of abstract interfaces, derive from all of them, and
pass around references or pointers of the interface types to
the users of the class?
Introducing roles that way. We probably could, but again, is it
worth the bother.
Don't take my comments too literally. I was doing a bit of
brainstorming. Trying to look at the problem from different
points of view. In practice, classes are a lot smaller than
applications, and each class has a lot less functionality. So
adding some concept of roles is almost certainly a lot of excess
complexity for very little benefit. At the sub-system level, it
often does become interesting, and there, having the sub-system
present several different fassades, depending on the user, is a
more or less standard technique.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]