Re: [GnomeMeeting-devel-list] [PATCH] removes unneeded begin/end call notification in text-chat

[Damien Sandras <dsandras seconix com>]

Le sam 24/01/2004 à 13:56, PUYDT Julien a écrit :
> On sam, 2004-01-24 at 11:36, Damien Sandras wrote:
> > > Well, no I haven't, and in fact, I don't really see why it is needed...
> > 
> > A GObject? Because it is a clean way to create new widgets with an
> > object-oriented approach.
> 
> Hmmm... I hadn't a real object-oriented approach in mind ; what I would
> like to see is certainly much more simple and conservative (but still
> probably too much for 1.00):
> 
> * in gnomemeeting.cpp, you would see:
> ** in the constructor: gnomemeeting_foobar_init ();
> ** in the destructor: gnomemeeting foobar_reset ();
> and elsewhere calls to gnomemeeting_foobar_feature (...);
> 
> * In foobar.h: the declarations of those "api" functions.
> 

That's exactly the way it is currently in most cases.

> * In foobar.cpp, in that order:
> ** the includes;
> ** some private variables declaration (static);

You will never see that. Global variables, even static, are considered
as a very bad programming practice by many people, including me and I
have put much effort to prevent that to happen.

> ** the helper functions' declarations;
> ** the api functions' definitions;
> ** the helper functions' definitions;


> > Because static variables wouldn't work in all cases (by definition of
> > static, they are local to a method, except if you want to make them
> > global).
> 
> I want them neither global nor local to a method. I want them defined
> and used only in the file where they're used, and only accessible
> through a precise api.

I know several projects using this, but my formation psychologically
refrains me from doing so. I will be very clear about this :
- either a GObject is used
- or you define structures like it is now

But you will never see semi-global static variables in any file of
GnomeMeeting, because it is nearly as bad as GOTO programming.

> 
> >  You would then end up with a mix of structures and of static
> > variables, which wouldn't be good either. So the CODE Policy is now to
> > either use structures declared at an appropriate place (could be
> > elsewhere than common.h), or GObjects.
> 
> No structure here, only variables accessible to all the code that needs
> them, and only to the code that needs them.
> 
> > Not so near, but near enough. If we release 1.00 in February/March, it
> > means we could also release a GnomeMeeting version with enhancements,
> > but based on OPAL and still H.323-only for the summer. Then we could
> > have SIP and IAX later.
> 
> Oh, what I have in mind probably wouldn't take that long: it's basically
> keeping the same code but moving the declarations and initializations
> around.
> 
> > Not really, both can be done at the same time. Porting to OPAL will only
> > change the endpoint.cpp, and connection.cpp files.
> 
> That sounds wonderful... then why two branches? ;-)
> 
> Snark
> 
> _______________________________________________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- 
 _      Damien Sandras
(o-     
//\     It-Optics s.a.
v_/_    GnomeMeeting: http://www.gnomemeeting.org/
        FOSDEM 2004:  http://www.fosdem.org
        H.323 phone:  callto:ils.seconix.com/dsandras seconix com