Here's Here's a link to help illustrate the difference between self:: and $this->. I have a hard time explaining this one, otherwise I would normally translate this for you. The more helpful of the answers, in my opinion, is the second one. But the first answer as well as a few others are pretty good too, they just expect you to already understand some of the more advanced OOP concepts. Corbin had a good explanation, but it seemed somewhat vague. No offense to Corbin, he's a good reviewer, but this is a difficult topic to explain (at least for me).
Here's a link to help illustrate the difference between self:: and $this->. I have a hard time explaining this one, otherwise I would normally translate this for you. The more helpful of the answers, in my opinion, is the second one. But the first answer as well as a few others are pretty good too, they just expect you to already understand some of the more advanced OOP concepts. Corbin had a good explanation, but it seemed somewhat vague. No offense to Corbin, he's a good reviewer, but this is a difficult topic to explain (at least for me).
Here's a link to help illustrate the difference between self:: and $this->. I have a hard time explaining this one, otherwise I would normally translate this for you. The more helpful of the answers, in my opinion, is the second one. But the first answer as well as a few others are pretty good too, they just expect you to already understand some of the more advanced OOP concepts. Corbin had a good explanation, but it seemed somewhat vague. No offense to Corbin, he's a good reviewer, but this is a difficult topic to explain (at least for me).
On Extending Classes
As Corbin says. It is rarely necessary to extend a predefined class. Think of it like this. You should only "extend" a class if you want to add functionality to it. Functionality mean a new feature. This does not mean, usually, redefining the entire class. Using a class is not the same as extending it. In this case you want to "use" the class, not "extend" it.
Some things about PHPDoc
I don't know how it is treated in other IDE's, but on netbeans (and I'm pretty sure eclipse) your PHPDoc comments do not show up because they are not in the (proper format)[http://www.phpdoc.org/docs/latest/for-users/anatomy-of-a-docblock.html]. This means the IDE doesn't know what to display when you try to use it, which makes these comments mostly useless. The link should help with any further questions that I don't cover in this section. The way you are currently doing it, it is just treated as a normal comment and therefore ignored. To initiate a PHPDoc comment you MUST use two asterisks /** to open it. A simple search and replace can fix that for you. Also, the "access" parameter is unnecessary, that should be documented somewhere on that site I linked you, but they changed it since last I looked and I'm not sure where it is anymore. I also don't think the "constructor" parameter is used anymore either, but I can't swear to that one.
/**@var mixed $stmt Used as a temporary variable to hold queries*/
/**allows easy instantiation and multiple database connections.
*
* @param mixed $db When array(), var holds all parameters required to connect.
* When string, var holds the type of DB to connect to. E.g. mysql
*
* @param string $serverHost the host of the DB connection
* @param string $dbName the name of the database
* @param string $dbUser the respective name of the user
* @param string $password the password of the user connecting
* @param bool $persistent if true, allows connection to persist through the app
*
* Database __construct ( mixed $db, [ string $serverHost = Null], [ string $dbName = Null],
* [ string $dbUser = Null], [ string $password = Null], [ bool $persistent = Null])
*
*/
The PHPDoc inside your methods ARE useless. Even if they did have the proper syntax, they would do nothing because they are located in the wrong place and are only making it difficult to read your methods. All of your interior DocBlocks should be combined with their exterior ones. Its also redundant and unnecessary to rewrite parent PHPDoc comments. If the parent class has documentation, the child class inherits that as well as any methods and properties. The only time this becomes an issue is if the child method does something completely different than the parent method, but then you are doing something wrong.
Here's another cool thing about PHP properties/PHPDoc comments. Though this is purely preference, I find it easier to keep my properties together this way :)
private
/**@var mixed $stmt Used as a temporary variable to hold queries*/
$stmt = Null,
/**@var mixed $scopeSelectVar Used as a temporary variable to hold queries*/
$scopeSelectVar = Null
;
Either way, you are definitely better about your documentation than I am. Keep that up and I'll aspire to be more like you :)
Self vs This
Here's a link to help illustrate the difference between self:: and $this->. I have a hard time explaining this one, otherwise I would normally translate this for you. The more helpful of the answers, in my opinion, is the second one. But the first answer as well as a few others are pretty good too, they just expect you to already understand some of the more advanced OOP concepts. Corbin had a good explanation, but it seemed somewhat vague. No offense to Corbin, he's a good reviewer, but this is a difficult topic to explain (at least for me).
If you take nothing else from that link, just remember self:: is static (as is anything with ::) and $this-> is not. You commonly see this syntax in child classes when overriding parent methods where you use the parent:: to call the parent's version of that method (or property). So the below snippet, and any others like it, should not use self:: because those methods are not static.
$param = self::defineParamType($val);
Comments
Endif, endfor, endforeach, etc... All comments along these lines, at least if you have a common IDE, aren't all that helpful. All IDE's, at least all the good ones, have brace matching highlighting, and usually code folding too. Either of these features is usually enough to find the end of a block of code. The comments typically just add noise. So this comment below is unnecessary. In fact, most comments inside methods should be avoided or only used for development.
//if Var $db == array() then connect using array parameters
Don't Repeat Yourself (DRY)
Along with many other principles, the DRY principle is a key point of OOP. Another good one is the Single Responsibility Principle, which is something Corbin was driving at. The names usually explain the principle fairly well. In this case, don't have repetitious code. Usually this means creating a function or method or loop. But in this case, it means moving things around and assigning new variables or redefining existing ones. So, for example here is your constructor, rewritten to use this principle.
$persistance = array( PDO::ATTR_PERSISTENT => $persistent );
$type = $db;
if( is_array( $db ) ) {
$type = $db[ 'dbType' ];
$serverHost = $db[ 'Host' ];
$dbName = $db[ 'dbName' ];
$dbUser = $db[ 'dbUser' ];
$password = $db[ 'dbPassKey' ];
}
$conn = "$type:host=$serverHost;dbname=$dbName";
parent::__construct( $conn, $dbUser, $password, $persistance );
Of course, you could use extract() above to an even better effect, but not many people like extract() or its counterpart compact(). The reasoning being that they are difficult to debug for. I believe that so long as the variables expected are being documented and the source is trusted, you should be fine. So the use of these functions are entirely up to you.
Escaping Variables in Strings
You may have noticed in the above section that I did not define $conn the same way you would have. I removed the braces from inside the strings because they are unnecessary. When declaring simple variables inside a string, it is only necessary to use PHP's escape sequence, "{}", when the variable name is likely to run into another word. For instance:
"{$verb}ing"
The only other time it is necessary to use the escape sequence is when using complicated variables. Such as:
"host={$db[ 'Host' ]}"
//OR
"host={$this->host}"
When in doubt, it wont hurt, but it makes it harder to read. Depending on the implementation it is sometimes just better to manually escape these sequences yourself.
Template Language
PHP is sometimes considered a templating language. One of the features that highlights this is the alternative syntax for its statements. For instance if: endif;. The colon and endif are the alternative syntax. Typically this is seen only in templates. So seeing it inside a class is quite odd, especially when not combined with the other alternatives. You should be consistent, and honestly you should only use this format in templates. It's a stylistic choice, but one most of the community agrees with.
switch( $var ) {
case 1 :
//contents
break;
//etc...
}
Exception Handling
I'm no expert here, but I believe the proper way to do exception handling is merely to throw the exception if one is found then catch it during implementation. So all of these try/catch blocks are unnecessary and redundant.
Conclusion
It was about at this point that I stopped reading. A lot of it appeared to be repeat issues or things Corbin already covered. As Corbin said, this is a good start. Keep up the good work!