Subject: Re: some comments about our C++ code...
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Sun Apr 15 2001 - 18:01:04 CDT
On Sun, 15 Apr 2001, [iso-8859-1] Joaquín Cuenca Abela wrote:
>
> 3) Please, please, please: NO public/protected variables. Period. Try
> to avoid public virtual members, too.
> This one need a bit of collaboration from everybody. I will not go
> through all the code and fix that. It should be fixed in an incremental
> way with the help of everybody.
HI Joaquin,
OK I have been guilty of violating this rule in many
dialogs. Mike Nordell has told me off for doing it but it seemed the best
way to implement some things.
Specifically the XP layer of a dialog seems the natural place to hold
variables concerned with the XP stuff in a dialog. In some dialogs there
are a lot of XP variables. It just seemed natural to put them into
"protected" space where they are accessible directly from the platform
code. Then rather than write a whole lot of get/set functions, and in the
case of vectors this is even sillier, it seemed more natural to make
these variables accessible to the sub-classes where they can be
read/written directly.
Specifically if you genuinely need to read and write a variable in a
subclass why put an extra layer of complexity between what you need to do
and what you're actually doing?
Another example is the fp_PageSize class in PD_Document. It just makes
sense to leave this as a publically accessible class. Otherwise one would
have to effectively duplicate all the methods in this class within
PD_Document to change anything about it.
One example that is rife throughout the Abi code is the gnome FE code
where the main Window widget pointer is left in protected space where it
can be accessed and set by the over-loaded _constructWindow methods.
Cheers
Martin
Motto: Some rules are made to be broken.
This archive was generated by hypermail 2b25 : Sun Apr 15 2001 - 18:01:44 CDT