[interfacekit] Re: BRoster & BWindow

> Hi Adi,
>
> It looks like we agree in all but one point of the discussion, so I
> take the liberty and remove all "unused" parts of the discussion :-)

    Well... not quite, but so be it!

> > > Direct member access is a major pain in every class library you
> > > write.
> >     YES, it is! ... when you are in public area !
>
> Not only that, because...
>
> > > It's just so easy and nice that everybody does it for small (or his
> > > own) classes.
> > > It's not recommendable for a public and huge API like the BeAPI is.
> >     Let me say that, I do agree with that affirmation! But, ( there
> > always
> > is a but. :-) it does not always apply! I cannot use an private
> > accessor
> > classes between BWindow an BView! It complicates things! It is
> > BWindow who
> > manages some of BView's members; BView only access them(I don't know
> > for
> > sure now, but I think there are some members that BView doesn't even
> > read or
> > write!).
>
> ... classes don't stay the same. They are constantly changing and
> evolving.
> Sure, with direct member access, you can write a perfectly
> working API.
> But it won't be less flexible and not as easy to understand when you
> actually have to change anything. Suddenly, you change values in places
> where it's not allowed to do, or you free an object although you
> mustn't anymore, or you just change one value but don't update another
> which depends on it.
> That's all solvable, but using accessor methods, you save much headache
> later on. Sometimes even in the original implementation.

    I would like to change/solve the problem at the source,
not go around it!!! I again say! The values we pass to private functions
are, all of the time correct. And, in my opinion, I would not write code in
an accessor method to solve a problem, but, I will go and modify things in
the method in question! Sorry, I don't like to patch things! In an API as
big as BeAPI is, all things should work in harmony, not with wheels within
wheels!
    And, again, my opinion, is that, in those accessor methods not much of a
deal is to be made. When a flaw is discovered, we should right away go to
the source of that error! Sorry I do not agree accessor method mechanism!

> > PS: an example! This I consider poor design:
> >
> > class BRoster{
> > private:
> >     friend RosterPrivate;
> > }
> >
> > class RosterPrivate{
> > private:
> >     friend BWindow;
> >     void UpdateActiveApp(...){
> >         roster->UpdateActiveApp(...) // that's all !!!
> >     }
> > }
> >
> > What is point in that=3F=3F=3F The same would go for a LOT of
> > BWindowInternals
> > methods, if implemented!
>
> How else would you do it=3F
    :-) Direct member access!

> A private friend accessor class has the advantage of hiding the
> implementation and doesn't export class internal functions to the
> outside.
    OH... my god! So what if it exports internal functions? It exports them
only to those who it knows!!!

> Although it's not that convenient when implementing the class, and it
> doesn't look that nice either, it definitely has some advantages, that
> should outweigh the disadvantages (in comfort).
    Yes, "some", I might say, minor, because arguments will be valid!

    Guys, I do agree that the accessor mechanism is "a good idea", as Erik
said, but, its not usefull ! As I see things, ALL the code written for
accessors, is ALMOST in vain. I don't see much problems coming up, that, we
actually have to resolve in accessor methods!

    I see here the classic difference of opinion between programmers. If
this discussion is to continue, people, please, come with something CONCRETE
sustaining accessor mechanism. And, please, don't give just one or two
examples, but, give me a rock solid argument, not like you did until now:
"It MAY happen...".


Adi.

Other related posts: