Re: $this assignment and call_user_func question
| From: | Melvyn Sopacua | Date: | Tue, 15 Jul 2003 23:27:52 +0000 |
| Subject: | Re: $this assignment and call_user_func question | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-3432@lists.php.net to get a copy of this message | ||
Hi Marcus,
On Wednesday 16 July 2003 00:11, Marcus Börger wrote:
> Wednesday, July 16, 2003, 12:08:29 AM, you wrote:
>
> GB> Hi,
>
> GB> I've heard rumors that there are plans to take away the ability to
> GB> assign to $this in php 5. If this is true, I would like to place a
> vote GB> to keep it, as it can be very useful in conjunction with
> GB> __call()/__get()/__set() to implement run-time aggregation seamlessly
>
> Why do you want to trick yourself and the engine? Can't you find a correct
> solution?
I'm not farmiliar with the example Greg is getting at, but the following bit
me recently:
class DomFromString extends DomDocument
{
function DomFromString($string)
{
$this = domxml_open_mem($string);
}
function foo()
{
echo('foo');
}
}
$doc = new DomFromString($xml);
$Root = $doc->document_element();
var_dump($doc, $Root);
echo($doc->foo()); // call to undefined function
I'm farmiliar with the trick-element of this code and why it won't work, but
the way to do something similar now, is to *not* extend the extension
provided class, use a $this->real_instance and provide methods that re-route
the already existing methods to $this->real_instance.
Unless there's something I'm missing, I find the latter solution has a much
larger trick element and adds a lot of unnecessary typing.
Note that the goal here, is to extend a class of which may not have the source
(or the time/ability to modify it) AND override it's constructor or the
constructor is provided by a function, rather than 'new' principle.
> Marcus mailto:helly@php.net
--
Melvyn