Hi, Mark
I'd say that probably 75% of the instance/class variable visibility was
well-chosen at inception, or at least had some thought behind it. But
history, as you suggest, has very likely left some visibility too broad, and
I'm sure some variables have been completely orphaned; others are probably
still being set but aren't in use.
It doesn't hurt to question the existence of any variable you run across,
let alone the qualifiers. I think the usual rules apply to us in FOP just as
they do to anyone else. If someone is using 'protected', for example, I
would expect them to demonstrate (or suggest the reasonable possibility) of
subclasses coming into play.
I have deliberately used public instance variables - not many, but a few.
I use them when I know for a fact that I am never going to represent the
data any other way. I have seen classes (and FOP has a few of its own) that
are unwieldy and hard to maintain because there are umpteen getters and
setters that are never going to be anything other than pseudonyms for
simple, direct access to a public member variable.
My gut feeling (well, it's actually based on some experience) is that
default visibility is an oversight, more often than not.
We should also comment qualifier choices if they don't make obvious sense
within the context of their own class.
Regards,
Arved Sandstrom
At 09:38 PM 7/16/01 +1000, Mark wrote:
Hey there foptologists
I was just wondering if there has been any discussion about private vs
non-private member fields for the FOP classes. I have noticed that there are
a lot of non-private (generally package-private default visibility) member
fields and most of them do not appear to be referenced anywhere else in FOP.
Unfortunately when changing a package-private field one must recompile the
entire package to make sure something isn't thereby broken. If a field is
class-private then one can be sure that it is not used anywhere else and can
change it with (relative) impunity.
Now I know that I am just saying stuff that everyone knows, so I was
wondering if there was some explicit reason for the use of package-private
or protected member fields instead of private members? Or is this just a
consequence of the long history of FOP?
I'm quite happy to refactor any code that I work on, this includes
privatization and formatting cleanups, but I don't want to annoy anyone else
who may have terribly good reasons for The Way Things Are. I am no PC
(programming correctness) zealot, I've just found through personal
experience that private member fields save a lot of pain. Am happy to go
with the 'quo, tho. :-)
Finally - is there an IRC server where FOP developers hang out?
Cheers
Mark
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
