> What I meant was that at one point you need to access a preference in a > function somewhere deep inside a class where you originally didn't need > access to the preferences object so you didn't provide access (through a > pointer/reference). Then you have to update all calls that lead or can > lead you into the function where you need the preference, which can be > quite a bit of work (and break all other code). Of course the standard
Just to stretch this even further OT, anyone who has tried Java will know that you CAN'T have globals - you have no choice but to pass things around. This is a fairly good discipline, and it really doesn't lead to code that's particularly messy - at least I haven't found that so far. For me, I would not declare plain (mostly native data type) variables global, but I would declare certain objects that have system-wide scope - for example, a file manager, or a custom database, or a units conversion manager, etc. I would interpret that reason for "globals being bad" as being because it provides uncontrolled access to variables - the same evil as making member variables public to avoid having to write and use Get/Set methods as some people do. To me, having system objects global doesn't 'encourage' as much abuse as plain variables. -- Jason Teagle [EMAIL PROTECTED]
