FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » FUDforum Development » Bug Reports » GLOBALS.php "Bug"??
Show: Today's Messages :: Unread Messages :: Polls :: Message Navigator
| Subscribe to topic | Bookmark topic 
Switch to threaded view of this topic Create a new topic Submit Reply
GLOBALS.php "Bug"?? [message #165087] Sat, 23 April 2011 07:43 Go to next message
Dayo is currently offline  Dayo   Bahrain
Messages: 101
Registered: April 2011
Karma: 0
Senior Member
add to buddy list
stop ignoring messages by this user
I have been facing an issue with calling GLOBALS.php externally and in summary, the issue is that the various variables are initialised in GLOBALS.php based on the assumption that the file is always included within free standing procedural code.

For instance, assume a variable $XYZ = 123 is loaded in GLOBALS.php

When I include GLOBALS.php from within a function in an external application, Variable $XYZ is no longer global in scope but is now local to my function simply because of the way the application is structured.

If I then later try to use fudapi.inc for instance, references to $GLOBALS['XYZ'] will return a null value.

It seems to me that there are some pretty significant, if not day to day, structural issues that need attention.

Stuff like the "globals", db.inc etc should be put into classes and they can they be referenced everywhere simply by $Config->XYZ or $db->abc after a class_exists test to check in they have been loaded before. Even this can be done away with if a set of classes is loaded early in the flow in index.php for every call.

Anyway, this would be a fundamental change if agreed to and probably one for a bigger point release.

As an interim, perhaps $XYZ = 123 could be written as $GLOBALS['XYZ'] = 123 in GLOBALS.php as an interim step.

Not thought about the implications though

[Updated on: Sat, 23 April 2011 07:44]

Report message to a moderator

Message by Ernesto is ignored  [reveal message]  [reveal all messages by Ernesto]  [stop ignoring this user] Go to previous messageGo to next message
Message by Dayo is ignored  [reveal message]  [reveal all messages by Dayo]  [stop ignoring this user] Go to previous messageGo to next message
Message by Ernesto is ignored  [reveal message]  [reveal all messages by Ernesto]  [stop ignoring this user] Go to previous messageGo to next message
Message by Dayo is ignored  [reveal message]  [reveal all messages by Dayo]  [stop ignoring this user] Go to previous messageGo to next message
Message by Ernesto is ignored  [reveal message]  [reveal all messages by Ernesto]  [stop ignoring this user] Go to previous messageGo to next message
Re: GLOBALS.php "Bug"?? [message #165129 is a reply to message #165127] Sat, 30 April 2011 04:39 Go to previous message
Dayo is currently offline  Dayo   United Arab Emirates
Messages: 101
Registered: April 2011
Karma: 0
Senior Member
add to buddy list
stop ignoring messages by this user
Quote:
From the bottom of my heart I do not mean any offense

No offense taken at all and I hope none is given by my posts as well.

Quote:
If that makes sense?

It does, 100% ... and makes my point as well which perhaps I have not been able to explain clearly enough.

I know what the variable scope is and what needs to be done with respect to this.

My point is precisely that putting items that will not change during the lifetime of the request into variables and then having to do the scope shuffle is a structural weakness or to put it bluntly, the result of a poor design choice.

All the variables in GLOBALS.php should have been either:

1. Declared explicitly as "GLOBALS['XYZ']" and always referenced as "GLOBALS['XYZ']". In this way, they will always be in the global scope wherever GLOBALS.php is included and since they are always referenced as such, in the situation I described earlier, I wouldn't need to be declaring globals this and globals that in my function. At present I have to declare "globals Every, Single, Variable, In, GLOBALS, Dot, PHP, One, By, One" or at least "globals Every, Single, Variable, In, GLOBALS, Dot, PHP, Used, In, The, Functions, I, Need, One, By, One" which is not good.

2. Defined as constants. The values are not going to change so why put them in variables instead of constants and then start doing the scope shuffle? If GLOBALS.php had contained "define('CONFIG_XYZ', 'abc')", whenever you need the value, all you do is use "CONFIG_XYZ" and that will be that.

3. Make it a class. Include and refer to class variables


However, you have chosen to do it the way it is now and of course I realise that the way it is currently set up makes no big difference internally within the application since you just use "$XYZ" or "GLOBALS['XYZ']" as required, but the reality is that if you had been delibrately trying to make the application unfriendly and difficult to extend/integrate, you couldn't have done a better job.

This loose structure fills every aspect of the code I have looked at. There are functions that appear as many times as the number of themes plus one. Grep one of the the functions db.inc and you will find it appearing multiple times in different places. This is bad, bad, bad ... but I don't want to go there now and just hope what I am saying about the GLOBALS.php thing is understood at this point.

[Updated on: Sat, 30 April 2011 04:44]

Report message to a moderator

Quick Reply
Formatting Tools:   
  Switch to threaded view of this topic Create a new topic
Previous Topic: SQL Error has occurred...
Next Topic: NNTP Import Subject with Non-Ascii Characters
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Jan 27 21:21:03 EST 2022

Total time taken to generate the page: 0.00848 seconds