* Greg Donald <destiney@xxxxxxxxx> : > On 6/8/05, Greg Beaver <cellog@xxxxxxx> wrote: > > If you want to compare object methods versus functions, you should > > compare identical code inside a method to code inside a function. > > Greg's benchmarks compare two different ideological code structures. > > Quite honestly, the wrapping of mt_srand() inside a function or method > > does not satisfy the definition of good coding, object-oriented or > > otherwise. > > > > Functions/methods should be used to abstract common operations. > > mt_srand() already does this necessary abstraction, and putting a > > further wrapper around it makes no sense. > > I called mt_srand() inside the constructor, so it's only called once, > same as the procedural version. This being an example of a class, it > seems like the logical place to put it. I can remove it from both > versions but it's not gonna change much as far as speed. > > > If your code does simple operations on a few operands and returns a > > value, like our mt_srand() function, there is absolutely no point in > > making it more complicated. > > I agree. In the real world a given task will likely be more > complicated, but that's not the point here. Actually, that is the point. What Chris was getting at is that usually you have a bit more going on in a function or method -- several operations, not just a wrapper for a single operation -- that the function/method call serves to abstract. So, calling a method that simply calls and returns a single php internal function call isn't going to give a good comparison; we already know that calling the function is faster. > > However, you could consider wrapping the functions inside a class and > > using them as static methods. > > There is little point in making classes to then only use the methods > statically. You could just put all your similar functions in an > include file and be done with it. Nothing more annoying than working > on someone else's OO code and seeing Foo::bar() all over the place. > Pointless. Unless you have several function libraries that were developed separately and *do* have the same function names. Where I work, for instance, at one point we had three function libraries, developed separately, that each had their own 'send' function, which worked fine until we tried to develop an application that mixed some functionality from the different libraries. Granted, we could have refactored and split out the common functionality from the libraries into a separate library, but we found it was much easier to wrap everything into classes and uses the class structure as a namespace. (We've since completely refactored and gone all OOP, but that's neither here nor there.) > > This would essentially give them a > > "namespace" that would allow any conflicts with other programmer's > > function names to be more easily resolved. > > If PHP needs namespaces then add them, last I heard the consensus was > that it didn't. I've never needed them personally. It doesn't seem > like enough justification to use objects just because you don't want > to rename a few functions in the rare event you actually have a > conflict. Seriously, how many times have you been working on a PHP > project that was so big, with so many developers, that you bumped into > each other with function names? Has yet to happen to me. That's *your* experience. You're going to keep seeing namespace discussions pop up whenever other people have experiences that indicate namespaces would help solve the issue. You're also going to have the issue pop up whenever you have developers from other languages start using PHP. I come from a perl background; I'd *love* to have namespaces in PHP... but I can use classes to emulate them fairly well. <snip> > > make the code readable and maintainable and it will cut down on bugs and > > work better than "faster" code. > > I always value efficient code over time to code. Doing more with less > hardware should always be a programmer's first goal in my opinion. > The overhead involved in bringing a web-based object into existence > for the extremely short period of time it will live can never justify > the 'maintainability' and 'readability' arguments I'm always hearing > preached. I've never seen any OO PHP code that was easier to read or > maintain for that matter. Again, your experience. I *have* seen OOP PHP that was easier to read and maintain. I've seen (and written) some perfectly horrendous procedural code that was a nightmare to read and maintain. You're right -- you should try to write efficient code. But sometimes you have to look at programmer efficiency as well -- if you're working for a client under a deadline, you don't always have that luxury. -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association | http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:matthew@xxxxxxxxxx | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
