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

    Why not let the class to have multiple friends that can modify its
internals, following the specifications!?! It's the same as using an
accessor class. After all, this only friend, modifies the class members
according to specifications.

>
> >     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.
    Please take the example of BWindow and BView classes! The mechanism
WON'T work if not removing the class encapsulation! After all, you realized
that when proposing a FRIEND accessor class, didn't you?

> You will generate more dependencies and
> strange reactions than you could memorize.
    Those 2 are big classes, do you think, I would get to work before
writing specifications?? Specifications, that are being updated while
writing code.

> 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.
    Your point of view!

>
> > > 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 :-)
    :-) unfortunately.

> Anyway, I think we need a decision for the kit, and so I am also
> pointing my fingers in Erik's direction.


    I just want you to understand, that, I perfectly understand the
accessors mechanism (you might say I don't :-). Instead, I don't see it to
be much useful in the area that you are proposing.
    BUT, again, my opinion,

    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.


Adi.

Other related posts: