[interfacekit] Re: BRoster & BWindow

"Adi Oanca" <e2joseph@xxxxxxxxxx> wrote:
> > 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!

If there was more than one point we were disagreeing on, I am sorry! 
Feel free to add this part of the discussion again.

>     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!

Removing the class encapsulation is a very big problem and really 
shouldn't be underestimated. You will generate more dependencies and 
strange reactions than you could memorize.
That's already true for smaller APIs but even more for as complex as 
Be's - one that even has to stay binary compatible where you can't just 
solve flaws as you might want to do it.

> > > 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=3D3F=3D3F=3D3F The same would go for a LOT of
> > > BWindowInternals
> > > methods, if implemented!
> >
> > How else would you do it=3D3F
>     :-) Direct member access!

That's not really an answer. It's a mile away from a solution.

> > 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=3F It 
> exports them
> only to those who it knows!!!

No, not with "friend"s. It makes part of the implementation public, and 
that reduces your flexibility in being able to further develop/change 
that class.

> ...
>     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...".

Well, I've given as much as I can, but if that doesn't help, we just 
continue to disagree on that very subject :-)
Anyway, I think we need a decision for the kit, and so I am also 
pointing my fingers in Erik's direction.

Adios...
   Axel.

Other related posts: