[interfacekit] Re: BRoster & BWindow

I'd like to start off by saying that if C++ had another access level -- 
let's call it "priviledged" -- which defined what only friends could 
touch (private would then be off-limits to *everybody*) I don't think 
this would be such an issue.  In the priviledged section, you could 
define all your "for friends only" functions.  Obviously, we don't have 
that, and so the private accessor class idea.

>    It can be VERY useful upgrading our code without breaking binary
>compatibility! We could use accessor classes to implement new
>functionalities. We could implement them as (full)methods in 
accessors(also
>using accessor's members), and then work with those; what I mean is, 
that,
>when not possible to use the original implementation, we will implement 
a
>modified version in the accessor class and work with that one. THEN, 
when
>the time for a new version comes, we would, almost copy the methods 
from
>accessors into the base class. To me it seems the ideal upgrade 
mechanism.
>
>    This is the only way that I see accessors being (more than)useful.

I have the feeling we will be doing some serious reworking of various 
classes in R2, and so Adi's point here is extremely relevant, and a 
strong argument for private accessor classes.

>    3) API private: used by the class in question, and by other API 
classes
>that need to read/write some datas from/into this class.(As I see 
things,
>that's exactly the purpose of BRoster::.UpdateActiveApp(...) [it's 
never
>called in BRoster's implementation]). There is no way to do that, 
unless
>using 'friend' keyword - at lest one! why not let the class to have 
multiple
>friends that can modify its internals, following the specifications!?!

The thing here is that the "specification" is implicit; private accessor 
classes make the specification explicit.  Whenever you make something 
implicit, you're relying on the assumption that outside classes are 
going to know what they can or can't tweak and how they can tweak it.  
Let's say that assumption is reasonable; for example, it's a small API 
that you have written entirely yourself.  Since you have *total* access 
to the befriended class's memory, there is a very real chance of 
accidently stepping on that memory in a way you didn't mean to, leading 
to extremely difficult to track down bugs.  Many chapters in many books 
give many more reasons why friendship is downright horrible or 
unnecessary in 99% of the cases.

>    Just curious! Where(in what API) did you saw private accessor 
classes
>implemented???

In Be's implementation, I don't believe there are any.  Right now, I 
think the closest thing we have to that is BLooperList, and that just 
aggregates already-existing friend functions and encapsulates the 
C-style looper list structure.

>I agree, that it seems we simply have different opinions about what 
would
>be a better design, and I don't think, further discussion will help to
>convince either side of the arguments of the other one. So, I guess the
>conclusion is to let the chief decide. Erik?

My preference would be to redesign the API so that we don't need the 
rampant use of friend.  I think it would be difficult and time consuming 
to do this.  In fact, it might turn out to be impossible to do and 
maintain source (not to mention binary) compatibility.  Something to 
explore post-R1.

Since it was my proposal, it won't come as a surprise to anybody that I 
think we should move ahead with private accessor classes.  So, that will 
be the interface kit team's official policy.

A last note:  rather than declare them as members of the classes they 
provide access to, I'd like to put them in the BPrivate namespace -- 
like BLooperList.  The idea being that if you declare them as class 
members, then they have to be in the public interface, and end-users may 
be tempted to use them.  Better to hide them away in BPrivate.

e

Necessity is the plea for every infringement of human freedom. It is the 
argument of tyrants; it is the creed of slaves.
        -William Pitt, British prime-minister (1759-1806)

Other related posts: