Re: [GnomeMeeting-devel-list] Ideas and considerations for the addressbook code

[Julien PUYDT <jpuydt free fr>]

�ic Bischoff a �it :
> > > Yes. You could have a few spare contacts before and after the user's
> > > view. This algorithm is rather common.
> > What do "before" and "after" mean ?
>
> Records just before and after the ones that are displayed in sequential order.

Sequential hurts.

> > > I know that it cannot be _that_ bad and that I certainly misunderstood
> > > something. But what?
> > I certainly have issues with big books, and must find some satisfying
> > way to handle them. But doing function calls to walk on a list where I
> > could get the list and walk it myself directly, is definitely wrong.
>
> What is wrong is to see that as a list ;-).

Indeed.

> > If I add a new addressbook type with a Foo capability, your designs says
> > I have to modify the base class and add:
> >
> > bool canDoFoo ();
> > void pleaseDoFooThisWay (...);
> > void pleaseDoFooThisOtherWay (...);
> > void etcFoo (...)
> > (with all the virtual pure syntactic crap needed)
>
> This "crap" is a lightweight modification since it is only one function 
> declaration. No implementation. That is done in the subclasses, if necessary.

Notice that I used "crap" to describe the syntactic need in C++ to add 
"virtual" and "= 0" everywhere.

And your "lightweight modification" still involves modifying the base 
class anytime a child class needs something!

> > My idea of right design is that if the new addressbook is the only one
> > needing Foo, it will handle it himself (through a specific api that its
> > view and controller will know and use).
>
> Okay. Perharps the our differences in opinion is not that much on the 
> programming design, but more on what the software has to do.
>
> To me, an address book is just an address book, they are not that different 
> one from the other. Ekiga need to dig through them to show names, categories 
> and to pick up SIP numbers to call the people. I see a relatively homogeneous 
> user interface, with more or less the same appearance (if not exactly the 
> same) for the various address books. I have a "unifying" vision.
>
> To you, all address books have very strong pecularities and the software has 
> to adapt a lot to each of them, to take them to the maximum of their 
> possibilities. The user will get different display, different menues, and 
> even different functionality.

Well, look at what we have to put already in the addressbooks:
- evolution-data-server addressbooks ;
- avahi contacts ;
- history contacts ;
- speeddials.

And the future holds :
- SIP contacts ;
- XMPP contacts.

> That explains why you want to put everything in the "drivers", while I want to 
> put a lot of common logic in the "engine".

Your high level is what I call low level : it handles all of the details!

> > Your view isn't OO, and isn't C++.
>
> Come on ;-).
>
> > You see functions named "methods" stuffed into the same poor base class,
>
> No. Again and again, the base class only has declarations. It sees an 
> abstraction of what the address book is.

You're still stuffing that in the base class, which is awful. Does the 
QWidget class have all the methods of all its child already declared?

> In every C++ book, you can see examples like this
>
> 	class vehicle {
> 		virtual void accelerate(int a) = 0;
> 		...
> 	};
>
> 	class car : public vehicle {
> 		virtual void accelerate(int a);
> 		...
> 	};
>
> 	class plane : public vehicle {
> 		virtual void accelerate(int a);
> 		...
> 	};

> Planes and cars have very different ways to accelerate. Planes can't brake and 
> cars can't fly, but such designs are clean and very popular.

They all accelerate, and that is the reason why having an accelerate 
method is put as a requirement in the base class.

Anyway I since made another proposition which I find neater ; I'm 
eagerly waiting for your comments on it :-)

Snark