Re: [SM-DEVEL] Ability to work with register_globals off

[Bruce R. <its...@uk...>]

On Mon, Jul 29, 2002 at 08:58:33PM +0200, Magnus Stenman wrote:
> hmmm; on which varibles would you use this function, and from
> where? if it needs to be done from wherever they are used,
> you might just as well convert those places to use the
> proper session varibles and emulate those centrally.
>=20
> when newer PHP versions get deployed, this emulation code
> would eventually never be called.

I disagree.  Extensive use of global variables is a bad habit.  Fetching
values from an array or object and having to explicitly set the values
in that object or array is good discipline.

Much of SM's code is very PHP3-like and doesn't take nearly enough
advantage of PHP's (very lightweight) OO model, IMO.  For example, there
are a lot of places where large chunks of code are duplicated in two or
three different files (like the address search code).

I'd like to encourage a more OO-based approach - it's more secure and
cuts down on some of the most common bug-traps.  It would have to be
done in a way that wouldn't break other non-OO code but the idea would
be to expand the coding philosophy across the codebase.

I have two simple examples I'd like to work on over the next week or so,
if nobody objects.  The first is the address book code as mentioned
above, the other is the prefs code.  I'd like to create a prefs object,
with db_prefs and file_prefs subclasses.  So as not to break any current
code, I'd put legacy functions into prefs.php that called the object
methods.  Then I'd like to add a method to the prefs object to allow for
mandatory settings as well as default ones.

As I said elsewhere in this thread, my ideal would be to have an $app
object and a prefs object within that, so that you'd call
$app->prefs->get, $app->prefs->set, $app->prefs->check and so on.

--=20
Bruce

I unfortunately do not know how to turn cheese into gold.