Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
OOP PHP help
- Thread starter zuma022
- Start date
- Sort by reaction score
Thanks for offering. I think I just figured out tonight's problem, but I'm still trying to get rid of an 'cannot redeclare class' error. The code is spread out over several files, I'm not sure what you'd need to see. I have three classes (db connections, users and orders) and two php files (login and orde form) that call methods from both. I've got all include_once, and I'm not quite sure why it won't let me use the class in more than one file, or I assume that's the problem anyway.
Use:
That makes sure you can't create two classes with the same name, regardless of how (redundant include/require, name collision, etc.) As a general rule, each class should be in it's own PHP file and loaded via "require_once" and with the structure I used above to ensure no name collision.
-jim
PHP:
if (!class_exists("classname")) {
...your class here...
}That makes sure you can't create two classes with the same name, regardless of how (redundant include/require, name collision, etc.) As a general rule, each class should be in it's own PHP file and loaded via "require_once" and with the structure I used above to ensure no name collision.
-jim
require_once() and include_once() are beautiful things.
I wouldn't use that - if I make a duplicate class, it's an accident; that ensures that my mistake is harder to track down, as PHP won't throw an error until I call an instance function or variable that isn't in the original, but the program still might run - with possibly interesting results. I'd like to catch my mistake sooner.
The true benefit of the class_exists() function is not about just your code. In the world of OOP which is not often discussed here it is common for developers to share classes and functions written by others as well as extend classes including those beyond just your own. In addition, a major component of quality development is error handling and parsing at runtime which catches such errors gracefully (i.e. an error triggered by calling a method of the wrong object in a dupe class name scenario). You cannot possibly test for all failure scenarios when the code starts getting complex. What I'm describing to you is a different mindset that pertains to larger projects, sure, but the approach can be applied here as well. I'm not saying you're "wrong", but asking you to expand your mind and realize these PHP commands do have a purpose in professional development and you should start using them as you advance in the OOP/PHP world.
-jim
Does your use of the second person refer to me or the original poster or perhaps a generic 'one'? Since you quoted me, so I'll assume it's me.
In which case, you can ditch the condescension. I am a professional software developer, and happen to do most of my work in OOP PHP. As it happens, I do use the class/function existence functions in my own work.
You neglected to mention in your first post that your code requires graceful error handling elsewhere, so I thought, and still think, that your code (as originally presented) is less helpful when testing than not including it. Throwing an exception would indeed make it useful:
PHP:
if (!class_exists("CLASSNAME")) {
...your class here...
} else {
throw new Exception('CLASSNAME already defined. Duplicate in ' . __FILE__);
}@NoNameBrand
First, you said: "I wouldn't use that"
Then, you said: " I do use the class/function existence functions in my own work"
I could waste time talking about the concept of "you" when quoting on a forum, or how you mistook a generalized comment like "in professional development" to infer you weren't a pro, or that I'm not pyschic.
Yes, of course I was referring to set_error_handler, which is a global and very graceful means of handling all errors in a script except fatal (which is not at discussion here with class name collisions which may be trapped). You took time to mention you use PHP's exceptions model - which is an alternative common in other languages but even that approach has a set_exception_handler. As your code has a "throw" in it, you are not using the handler which is really more efficient in a larger project (as I said previously). In short, I was talking about user defined handlers, that's all. As I said before, you're NOT wrong. Just an opinion on my part based on your code and comments, and don't take it personally if I happen to mention it's a more professional approach to ponder an alternative way compared to the advice given to the novices as the traffic here is often based. That's all, honest.
If you still think I'm flaming you, please get a grip and leave me alone.
-jim
First, you said: "I wouldn't use that"
Then, you said: " I do use the class/function existence functions in my own work"
I could waste time talking about the concept of "you" when quoting on a forum, or how you mistook a generalized comment like "in professional development" to infer you weren't a pro, or that I'm not pyschic.
Yes, of course I was referring to set_error_handler, which is a global and very graceful means of handling all errors in a script except fatal (which is not at discussion here with class name collisions which may be trapped). You took time to mention you use PHP's exceptions model - which is an alternative common in other languages but even that approach has a set_exception_handler. As your code has a "throw" in it, you are not using the handler which is really more efficient in a larger project (as I said previously). In short, I was talking about user defined handlers, that's all. As I said before, you're NOT wrong. Just an opinion on my part based on your code and comments, and don't take it personally if I happen to mention it's a more professional approach to ponder an alternative way compared to the advice given to the novices as the traffic here is often based. That's all, honest.
If you still think I'm flaming you, please get a grip and leave me alone.
-jim
The first statement was specifically referring to your if-class-exists-construct surrounding a class, as presented, with no exception throwing or error handling mentioned. Sorry if it was confusing.
Amusingly, I use error handlers in my projects instead of exception handling; I had tried exception throwing a few years ago (in PHP4) and it didn't work to my expectations (based on my experience Java programming), and I haven't really touched it since. I could've written
PHP:
trigger_error('foo');Wrapping a class definition with an if(class_exists()) statement is one of the ugliest things I've ever seen. Honestly, I don't see the point.
I disagree. If you have to gracefully handle errors for class naming conflicts, then you have a much bigger problem than gracefully handling conflicts. Large project or not, I think it's unnecessary friction caused by a "problem" that can be solved by better tools.
I disagree. If you have to gracefully handle errors for class naming conflicts, then you have a much bigger problem than gracefully handling conflicts. Large project or not, I think it's unnecessary friction caused by a "problem" that can be solved by better tools.
I understand each of your positions in the context in which you're both programming.
As to the function, my statement involved a different context, I think a very real and common situation where other classes and extensions of classes are involved. Just as an FYI, I also wish to add that function is very helpful to ensure a class was invoked properly via a plugin scenario where a user might extend your code externally. Or you want to see if the class has been properly de-constructed as part of memory cleanup. Matter of fact in PHP 5.0.0 they actually added a new parameter to support __autoloading, which I think is quite convenient when used properly and clearly demonstrates programmers were using the function.
I'm not asking either of you to change your style, but merely to be open to possibilities and situations others have experienced where they find the function quite useful. As to the user defined global error handler, I can't disagree about the bigger problem part - but there is no tool that can account for all failure scenarios in all projects all the time. So adding in a decent handler and using throws or triggers along with a few sensible safeguards such as this function will all work together making a complete end product. I know you each have different ideas and methods, that's cool.
I suggest you tell Zend to deprecate the command if you see no use for it with the same justifications you explained to me.
Thanks for expressing your opinions and thanks for listening to mine. I'm moving on to other topics, I'll leave the last word to anyone who wishes to do so. Cheers.
-jim
As to the function, my statement involved a different context, I think a very real and common situation where other classes and extensions of classes are involved. Just as an FYI, I also wish to add that function is very helpful to ensure a class was invoked properly via a plugin scenario where a user might extend your code externally. Or you want to see if the class has been properly de-constructed as part of memory cleanup. Matter of fact in PHP 5.0.0 they actually added a new parameter to support __autoloading, which I think is quite convenient when used properly and clearly demonstrates programmers were using the function.
I'm not asking either of you to change your style, but merely to be open to possibilities and situations others have experienced where they find the function quite useful. As to the user defined global error handler, I can't disagree about the bigger problem part - but there is no tool that can account for all failure scenarios in all projects all the time. So adding in a decent handler and using throws or triggers along with a few sensible safeguards such as this function will all work together making a complete end product. I know you each have different ideas and methods, that's cool.
I suggest you tell Zend to deprecate the command if you see no use for it with the same justifications you explained to me.
Thanks for expressing your opinions and thanks for listening to mine. I'm moving on to other topics, I'll leave the last word to anyone who wishes to do so. Cheers.
-jim
Error handling and Exception handling are not the same thing, even if an uncaught Exception will lead to an Error.
The whole point of Exceptions is that you can Throw a derived Exception class and then Catch it and handle the condition - without impacting on the overall task whenever possible, or at least handling the condition gracefully. Combining this with set_exception_handler seems the best solution, and set_error_handler to provide consistent error reporting.
If you use trigger_error then you loose this capability. I see no reason to use this function in an OO context unless you want the script to STOP for sure and produce debugging info.
For duplicate class names in complex projects...PHP introduces name spaces (about time) in 5.3.0.
The whole point of Exceptions is that you can Throw a derived Exception class and then Catch it and handle the condition - without impacting on the overall task whenever possible, or at least handling the condition gracefully. Combining this with set_exception_handler seems the best solution, and set_error_handler to provide consistent error reporting.
If you use trigger_error then you loose this capability. I see no reason to use this function in an OO context unless you want the script to STOP for sure and produce debugging info.
For duplicate class names in complex projects...PHP introduces name spaces (about time) in 5.3.0.
I understand each of your positions in the context in which you're both programming.
As to the function, my statement involved a different context, I think a very real and common situation where other classes and extensions of classes are involved. Just as an FYI, I also wish to add that function is very helpful to ensure a class was invoked properly via a plugin scenario where a user might extend your code externally. Or you want to see if the class has been properly de-constructed as part of memory cleanup. Matter of fact in PHP 5.0.0 they actually added a new parameter to support __autoloading, which I think is quite convenient when used properly and clearly demonstrates programmers were using the function.
I'm not asking either of you to change your style, but merely to be open to possibilities and situations others have experienced where they find the function quite useful. As to the user defined global error handler, I can't disagree about the bigger problem part - but there is no tool that can account for all failure scenarios in all projects all the time. So adding in a decent handler and using throws or triggers along with a few sensible safeguards such as this function will all work together making a complete end product. I know you each have different ideas and methods, that's cool.
I suggest you tell Zend to deprecate the command if you see no use for it with the same justifications you explained to me.
Thanks for expressing your opinions and thanks for listening to mine. I'm moving on to other topics, I'll leave the last word to anyone who wishes to do so. Cheers.
-jim
I think the command is valid for certain situations. I just wouldn't use it for that situation. I wouldn't wrap my classes with it. That's all I'm saying. Now, if I'm dynamically loading types based of entries in a config file, then I could use to ensure the type actually exists before I use it. Some type of plug-in model would be an example of that.
While no tool is 100%, catching something as simple as duplicate class names would be easily captured by a tool.
Again, not asking for them to remove a certain function. I'm just saying there are valid situations for everything and I wouldn't consider duplicate class names as being one of them.