On 15 Apr 2012, at 13:30, Lester Caine wrote:
> Stuart Dallas wrote:
>> On 15 Apr 2012, at 11:44, Lester Caine wrote:
>>
>>> I've got a machine set up with PHP5.4 and left the strict errors showing, and I'm falling at the first hurdle :)
>>>
>>> The functions for generating URL's are used both statically and as part of the class. STRICT complains because they are not marked 'static' ( and I'm assuming 'public static' is the correct addition here ) but then of cause the $this fallback fails because '$this' is not allowed IN the static use of the function?
>>>
>>> How do others get around this problem? I've some 120 static instances to fix in parallel with about the same number of class uses across about 40 odd functions. Do I really have to duplicate the code and rename every static use?
>>
>> If the class can be used both statically and as an instance why is it referring to $this? When called statically $this will not exist.
>>
>> To refer to the class when in a static method use self...
>>
>> <?php
>> class StaticClass
>> {
>> public static $staticVariable = 1234;
>>
>> public static function staticMethod()
>> {
>> return self::otherStaticMethod();
>> }
>>
>> public static function otherStaticMethod()
>> {
>> return self::$staticVariable;
>> }
>> }
>
> This is all legacy code only some of which I wrote, and the function IS working happily with 'STRICT' switched off. I'm just trying to work out how to remove the messages that switching 'STRICT' on creates - which in this case is complaining when the function IS called statically without being defined as such. The function creates a url based on the information supplied, and if no information is supplied it uses $this to access the data directly. The problem now is getting both uses of the function working, but it looks like I HAVE to duplicate the code ... or rather work out how to get the correct values selected before calling the static version of the code.
You don't need to duplicate code, you simply need to create different entry points to the class based on whether it's accessed statically or as an instantiated object. Something like this...
<?php
class UrlGenerator
{
public static function buildURL($a, $b, $c)
{
...
}
public function getURL()
{
return self::buildURL($this->a, $this->b, $this->c);
}
}
?>
No code duplication but clear separation between static and instantiated usage. However, this is not the best way to structure this code IMO. The better option would be to extract the static parts into a separate class, and use that new class from the instantiated version.
> With reference to the above, does self:: replace parent:: when trying to call the base functionality which is where I think I am trying to head ... getDisplayUrl() gives me a url in one of a number of formats depending what style of url is selected, and the base package that created it, so the use both statically and 'dynamically' made perfect sense 10 years ago :)
Using a class both statically and as instantiated objects makes sense now, never mind ten years ago, but it has never made sense for both uses to share the same entry points. It was possible, but that doesn't mean it makes sense.
The self and parent keywords do exactly what they say on the tin. Self refers to the current class and parent refers to the parent class, both in a static context. Some of these things are pretty self-explanatory.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
