I've made my own library in codeigniter and I have multiple functions with in the library.
Now these functions refer to a group of global variables.
Now what I've done inside the class is declare variables by saying protected $myvar; but when I refer to these variables within my functions,
I get errors saying $myvar is undefined... Please help...
In OOP context, you have to use $this->myvar, not just $myvar.
Related
In V8 at least, in the debugger, you see local, script and global categorizing the variables.
I got a reference to global. All you do for that is set this on entry to a property to use later if need be.
However, I can't find how to save a reference to the script object. I think it exists because that's what the debugger is looping through in the watch window.
Before ES6, All declarations outside a function (and function declaration themselves) were properties of global object. After ES6, There are two kinds of global records:
Object record- Same as ES5.
Function declarations
Function generators
Variable assignments var
Declarative record - New
let, const, class, etc
Those in the declarative record are not accessible from the global "object", though they are globals themselves. They are accessible from the script, but the object/internal data structure holding the declarative records itself is not accessible or enumerable from inside the script. This declarative record is shown in v8 debugger as properties of script object.
References:
Global environment records
Related Answers:
ES6- What about introspection
Do let statements create properties on the global object
We had Forify scan for our website code and fortify reported few issues. We are using CodeIgniter 3.1.9 framework. One of the issue they mentioned as
Possible Variable Overwrite' for function 'extract()' in file mysqli_utility.php.
As this is core file of CI framework, I'm not using this function directly and also I do not know where this function getting used by CI.
Will you please help to resolve the issue reported by Fortify? What could be the solution?
extract() imports variables from an array into the current symbol table. The phrase "current symbol table" basically means into the current scope of the code. For the usage in question, extract() is called inside a class method. So the current scope for the extracted vars will be in that method and that method only for that instance of the class.
CodeIgniter's core code does not define or use global variables. Unless code developed for the application uses globals (which it should not as "globals" are more of a "procedural programming" thing) the possibility of overwriting is exceedingly low.
I'm curious as to why the scan didn't pick up all the other times extract is used by CodeIgniter.
I'm writing a number of scripts that all depend on any number of "library" scripts.
My scripts are built together mainly with functions and in one of these functions named "init", I define the constants I need and try to import my libraries using "source". However, if I try to call one of the functions in the global scope or inside of another function it doens't seem to exist...
For declaring global variables there's "declare -g", is there an option like that for functions?
for reference, the scripts I'm writing reside here: Pegasus' Linux Administration Tools
Normally you can export function the same way as variables :
myfun() {
...
}
export -f myfun
I have a program that will grab several global settings from an API when first logged in. These values are then used extensively throughout the program. Currently I am storing them in global variables, but it does not seem very OOP.
What are the alternatives to global variables for storing extensively used settings? Use constants? Class variables? Where would I initialize the values through the API call, since this would only need to happen once? I have seen some examples that instantiate a class to get to the variables but that does not make much sense to me.
I would like to set the values on login and after this call the variables everywhere else with a simple expression like Global.myvalue or GLOBAL_MYVALUE
The Singleton Pattern might be handy for this:
https://ruby-doc.org/stdlib-2.1.0/libdoc/singleton/rdoc/Singleton.html
It's hard to give you a concise answer based on the information you provided, but I would avoid using global variables at all costs.
A good starting point would be to think of a class that could be a common ancestor to all the places where you use these variables and store them in that class. If your subclasses inherit from that class, these variables will automatically be available in their context.
Edit: like #seph posted, the singleton pattern seems to be a much better solution though
I have a class called Awesome and have used the ServiceProvider and the Facade to register it to the app. Now I can use it as Awesome::Things().
I want to add constants to this class, so I tried
<?php namespace Helper\Awesome;
class Awesome()
{
public static $MOVIE = 'I love the Lego Movie!";
}
but when I call Awesome::$MOVIE, I get Access to undeclared static property: Helper\\Aesome\\Facades\\AwesomeFacade::$MOVIE
Can someone help?
The short version is -- you don't really want to do that. Laravel facades aren't mean to be used like normal classes, and if your application uses them that way you'll likely confuse future developers.
Warning out of the way. When you create a "facade" in Laravel, you're actually creating a class alias. When you added Awesome to the alias list in app/config/app.php, at some point code like the following ran
class_alias('Helper\Aesome\Facades\AwesomeFacade','Awesome');
That means whenever you use a global non-namespaced class Awesome, PHP substitutes Helper\Aesome\Facades\AwesomeFacade. If you wanted to add constants, you'd need to add them to this class.
Laravel's able to pass through methods because of the base Facade class implements a __callStatic method that passes on your call to the actual service implementation object. Facades don't pass on static constant access. Additionally, PHP does not (appear to?) have similar magic methods for passing along requests for constants.
If you're curious about the in depth version of this answer, I'm currently writing a series on Laravel's object system, including some in-depth information about the facade implementation.