[dudewad]

Hey guys,
So I'm wondering in general what peoples preference is and why. Is it better (or does that even matter) to use a scope resolution operator or to instantiate an object of a class? In the case of a Utils class I can see using scope resolution operators because the class potentially has no properties to access anyways, e.g.:
Utils::doSomethingAwesome();
Vs:
$utils = new Utils();
$utils->doSomethingAwesome();

Firstly I thought that scope resolution operators were a dream come true especially from the standpoint of not having to instantiate a class that could be several thousand lines of code- which brings up the question "does file length affect performance in class instantiation?".

But then secondly, I'm wondering what kind of hidden performance setbacks there are when using scope res ops? You obviously lose the ability to get/set properties of an object, etc, but from what I can tell you don't have to worry about accidently making too many objects, etc. I do see scope res ops in lots of big, well-known code platforms so I figure it can't be a TERRIBLE idea... right?

I've been using them extensively and they seem great.

Anyone have any preferences/care to explain why? I'm just wondering, because I want to understand it to the fullest and I want to do my stuff RIGHT!

Thanks!

[ManiacDan]

Anyone have any preferences/care to explain why?

You said it already:

You obviously lose the ability to get/set properties of an object, etc

When calling object functions in static context (using the scope resolution operator) you lose the ability to treat an object like an object and instead you treat it like a library of functions that don't interact with each other or persist data.

from what I can tell you don't have to worry about accidently making too many objects

The singleton pattern takes care of that for you if you need it.

-Dan

[requinix]

The scope resolution operators have nothing to do with this. It's two characters versus two different characters.

The real question is static classes versus instantiated classes. A utility class, which is generally bad practice to use, is normally a static class because it has individual functions for specific purposes - there's no OOP involved (which is why it's a bad practice to try to make it OOP anyways).

If you have a static class then you should probably not have it. Just use normal, global functions. If I have a class I expect I should be able to instantiate it for something; in rare cases it'll be a container for very specialized functions, thus saving you from using long function names.

[dudewad]

Originally Posted by requinix

Just use normal, global functions..

My only problem is that I've been shying away from "global anything" precicely due to the sheer amount of "DONT USE GLOBALS IF YOU DONT HAVE TO" that I read everywhere. How can you make global function in a safe way?

And is a utilities class really that bad to have for things like, say, custom formatting of phone numbers or addresses or anything like that? I'm trying to get my head around how to be much more OOP oriented and going the route of MVC just seems overkill for most projects that arent very big.

Thoughts on that, sir?

[ManiacDan]

A "utility class" isn't really OOP, it's just a way to reduce your scope, similar to packages in other languages. It can't be a real "object" unless it contains its own data and functionality and works on internal operations (personal opinion sort of backed up with industry standard opinions).

Don't use global VARIABLES if you don't have to. Functions cannot be overwritten, so you won't have the problem of having a function called "doSomething" in one file overloading function doSomething from another file. PHP will simply die during testing.

If you're going to write a function like print_phone_number, it's fine to put it in the global scope. You could also make a utility class for it I guess, so you have myOutput::printPhoneNumber($number). You could also get super fancy and make your myOutput class rely on passed-in internationalization formats. That would be a true object, once it can be instantiated and store its own data. Using a singleton pattern you can do

myOutput::getInstance()->setLocale('UK');
myOutput::getInstance()->outputDate($someDate); 

-Dan

[requinix]

The people who scream about global stuff either (a) don't understand the point of global stuff, or (b) are repeating mantras they've heard without fully understanding.

For one, PHP is primarily procedural. There will always be a global scope with variables and functions and other things. That won't be going away.
Importing those variables into other scopes (eg, functions) with stuff like the globals keyword or $_GLOBALS is a misuse of variable scope. That is bad. But the entire global scope by itself is not bad, and shunning it simply because it has The G Word is ignorant.

There is no gain by using a Util::FormatPhoneNumber() static method over a formatPhoneNumber() global function. The only reason to do that in PHP is to try to use OOP principles - which have their place, certainly, and especially in languages like Java and C# where there isn't really a global scope. But in PHP you're better off trying to follow the patterns and suggestions of the language than forcing other principles into it.


On that note, MVC is powerful but can definitely be overkill for something. If the project lends itself to object-oriented design then go ahead and go MVC so you aren't mixing-and-matching procedural and OOP, but if you just want a simple site with a few dynamic pages, or even something more complicated than that, MVC might not be worth it.

Take this thing as an example. (It's one of the few publicly-accessible PHP scripts I still have.) Did I use MVC? Even any kind of OOP? No, because there was nothing to gain from it. I could have, but (a) it would have drastically increased the complexity of the script, (b) would have required overhead code just to get it working, and (c) would have taken longer to plan, design, engineer, test, debug, and maintain. That script is basically just a hardcoded multi-dimensional array and a couple loops.


With all that said I love OOP. It makes sense. It models the real world. But I'm rational enough to know that it isn't always worth it.

[dudewad]

That's what I was looking for! Thank you for you thoughts, sir! I always appreciate insight from those wiser than me
One more question, if you don't mind answering--

[QUOTE=requinix]For one, PHP is primarily procedural. There will always be a global scope with variables and functions and other things...]

Originally Posted by requinix

...in PHP you're better off trying to follow the patterns and suggestions of the language than forcing other principles into it.

Do you know of a good resource where i could learn more about these concepts? I'm not looking for introductory level stuff, maybe you have a blog you know of or an interesting article that discusses these ideas at more advanced levels?
Thanks a lot for you time and thoughts!

[requinix]

A lot of what I said was just opinion, really.

Fact: PHP is primarily procedural. Always has been.
Fact: That won't be changing any time soon.
Opinion: Adapt to a language - don't make the language adapt to you.

Best I can offer is for you to find an OOP/D book that isn't for PHP. (Java is probably your best bet.) There are so many false-positive blogs (which offer flawed advice and uneducated opinions) and articles (by minimum-wage or freelance writers who want to get their name out on the Internet) that I don't really keep an eye out for good content anymore.

[dudewad]

Thanks for being the bomb.

[kicken]

In the case of your utils:: example, I'd say what your seeing there and in other projects that do similar things is people using the classes as a form of namespacing, since until recently php did not have actual namespace support (5.3 added it).

I have done similar things in projects where I will create some clases which have quite a few static functions and the class name acts generally as just a name space.

That said, I don't create any "Utils" or other generic catch-all class, for functions like that I do just create a global function which I store in a functions.inc.php include file.

The classes I create contain function which all operate on the same basic concept. The way I use them could probably be converted into creating separate instances and methods, but I find the statics to work better in some casses ( had speed/memory problems before making a lot of objects vs just an array of info).

[Northie]

Although I agree with everything that has been said here, I do use a library/utility class for some functional stuff because I can reap the benefits of autoloading and namespacing.

By grouping related functions into single static classes I also reduce file size (at the expense of file includes) and have shorter, more meaningful function names.

When I first tried to get my head into OOP I tried to get involved with some strange OOPHP project which was aiming to make all an alternative php function library, eg

instead of str_replace(), there was str::replace()

strpos() became str:os()

It was a nice idea to streamline the argument order and underscore variations that occur within string and array functions, but the project died (as far as I am aware) and taught me little about OOP

[requinix]

Originally Posted by Northie

When I first tried to get my head into OOP I tried to get involved with some strange OOPHP project which was aiming to make all an alternative php function library, eg

instead of str_replace(), there was str::replace()

strpos() became str:os()

It was a nice idea to streamline the argument order and underscore variations that occur within string and array functions, but the project died (as far as I am aware) and taught me little about OOP

It's a good idea (that I've tried myself) but it's better more for getting a handle on how OOP works. I don't think it alone could teach any real principles or practices - more like something you'd see in a school OOP/D 101 programming course. Very Ruby/Java/C#-ish.

Nice to see I'm not the only one who thought "OOPHP"