On Thu, Jun 09, 2011 at 03:42:49PM -0600, George Langley wrote:

>       Hi all. Am fixing some inherited code, and the previous coder created a 
> class, ie:
> class myClass {
>       function &doThis($passedVar) {
>               doSomething;
>       }
>       function &doThat($anotherVar) {
>               doSomethingElse;
>       }
> }
> BUT, I don't see anywhere where he created an object, ie:
> $myObject = new myClass();
> or
> $myObject = myClass::doThis("value");
>       Instead, it's only ever just called directly with a "Scope Resolution 
> Operator", ie:
> myClass::doThis("valueOne");
> myClass::doThat($whatever);
> myClass::doThis("valueTwo");
> myClass::doThat($andSoOn);
>       It seems that this would be making an object, and then destroying it 
> again, on each of the four calls above, which I would think would be wasteful 
> - time, memory, cpu usage, etc.
>       The class has no constants or variables (properties) for any need for 
> persistence, and is just a collection of functions (methods), so I don't see 
> a reason to group them into a class - they could all reside as independent 
> functions within the php file.
>       Is this good? Is there some advantage to making a non-persistent class?
>       Thanks!

I'm not real good with static stuff, but he's essentially using calls to
what are [being treated as] static methods inside the class. I'm not
sure this means an actual object is being created. There's certainly no
reason to create one.

If these methods truly have no persistent members within the class, then
I agree, they can simply be external functions. These may be grouped
this way for logical reasons, but if I have functions like this (which
relate to a class but don't depend on the class), I generally put them
in the class source file but outside the class. They become global as
soon as the source file is include()ed.


Paul M. Foster

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to