| GLOBALS.php "Bug"?? [message #165087] |
Sat, 23 April 2011 11:43  |
 |
Dayo
Messages: 101
Registered: April 2011
Karma: 0
|
Senior Member |
|
|
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 11:44] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: GLOBALS.php "Bug"?? [message #165121 is a reply to message #165119] |
Thu, 28 April 2011 02:49  |
|
Dayo
Messages: 101
Registered: April 2011
Karma: 0
|
Senior Member |
|
|
I get what you mean now.
Should work in most instances but not a suitable way to go about things. I'll have to go through the code called by FUDforum, find every one of the variables and declare them one by one. This is hellish and should not be neccessary at all.
I can see that in some places the variables are referenced directly, $XYZ, and in some others, using GLOBALS['XYZ\].
Now this is fair enough within the application but a more disciplined and structured approach is needed as while this may mean more work at times, it will make the application more extensible.
Define the stuff in GLOBALS.php as constants (not variables, global or otherwise) at the beginning of the flow and that's that. We know they are not going to change so why a variable in the first place anyway?
From then on, "CONF_XYZ" for instance, can be referred to anywhere without fear of tripping over anything. You don't, as a third party developer, have to wonder wherether you need to use this form or that form in this place or that place or whether ypou need to do anything special or not.
Will make things clean, structured and extensible.
So not quite a bug as such but more of a weakness in the design structure ... one which affects many other things in the application in general and one which puts obstacles in the way of third party devs.
I came to FUDforum because a feature I wanted, mailing lists, was not available elsewhere but have now realised that it would have been easier for me to try write a plugin to do this for phpBB3 due to having to have to overcome these structural issues in the main application here.
I'll suggest that a step back is needed for the next bigger point release to look at these issues. Basically a more "OOP" based approach is needed I think.
Anyway, just my 2 pence as an outsider trying to get a bit deeper into things.
|
|
|
|
| Re: GLOBALS.php "Bug"?? [message #165127 is a reply to message #165121] |
Thu, 28 April 2011 13:20 |
Ernesto
Messages: 413
Registered: August 2005
Karma: 0
|
Senior Member |
|
|
If you include something in a function, the result will be local unless specifically defined as global within the function.
So if you include the file outside the function, it will be global or "public" using .NET terminology.
If you want to be able to access a local variable outside the parent function you have to declare it global or supergloba, either by declaring it within the global scope, or defining it as global within the function.
If that makes sense?
From the bottom of my heart I do not mean any offense, but I think you are mistaking this as a structural issue whereas in you are just "doing it wrong" as the lolcat would have said. But, I have been wrong a million thousand billion times before and this could sure as hell be one of those times again.
Ginnunga Gaming
|
|
|
|
| Re: GLOBALS.php "Bug"?? [message #165129 is a reply to message #165127] |
Sat, 30 April 2011 08:39 |
|
Dayo
Messages: 101
Registered: April 2011
Karma: 0
|
Senior Member |
|
|
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 08:44] Report message to a moderator |
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]