[PHP-INTERNALS] $this assignment and call_user_func question

Hello Greg,

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?

Best regards,
Marcus mailto:helly@php.net

Hi Marcus,

Hello Melvyn,

Wednesday, July 16, 2003, 1:27:52 AM, you wrote:

MS> Hi Marcus,

MS> On Wednesday 16 July 2003 00:11, Marcus Börger wrote:
MS> I'm not farmiliar with the example Greg is getting at, but the following bit
MS> me recently:
MS> class DomFromString extends DomDocument
MS> {
MS> function DomFromString($string)
MS> {
MS> $this = domxml_open_mem($string);
MS> }
This should be a factory patter...static function ...return domxml_open...

MS> function foo()
MS> {
MS> echo('foo');
MS> }
MS> }

MS> $doc = new DomFromString($xml);
$Root = $doc->>document_element();

MS> var_dump($doc, $Root);
echo($doc->>foo()); // call to undefined function

MS> I'm farmiliar with the trick-element of this code and why it won't work, but
MS> the way to do something similar now, is to *not* extend the extension
MS> provided class, use a $this->real_instance and provide methods that re-route
MS> the already existing methods to $this->real_instance.

MS> Unless there's something I'm missing, I find the latter solution has a much
MS> larger trick element and adds a lot of unnecessary typing.

MS> Note that the goal here, is to extend a class of which may not have the source
MS> (or the time/ability to modify it) AND override it's constructor or the
MS> constructor is provided by a function, rather than 'new' principle.


You can of course overwrite the constructor in a derived class and all. So you
are missing the possibility to exchange the contants of a dom clas, that's all
you do this tricky stuff for?

Best regards,
Marcus mailto:helly@php.net

Hi again,

On Wednesday 16 July 2003 10:01, Marcus Börger wrote:
[ ... ]
How would you know how to write the parents' constructor, if it's opaque?
If the constructor creates a resource, how would you mimmick this in PHP?
The dom class is an example, but let's not focus on dom here. It does
illustrate the problem however, because the constructor for a string based
DomDocument is the PHP_FUNCTION(xmldoc).

Which means, the following does not work:
class DomFromString extends DomDocument
{
function foo()
{
echo('foo');
}
}

$dom = new DomFromString($xml);
var_dump($dom);

This is because there are three *function* constructors, which do something
usefull, which are returning the same object. I really don't see a way, to
extend this object. The primary reason is: BC, missing methods, adding
convenience methods.

Since PHP5 should also give a boost to PECL, I think there should be a way to
extend a C-based class, somehow. I really don't favor the $this assignment as
well, but what other option is there? Or is this specifick for the way the
domxml module is setup, and people shouldn't write their classes like that?

Hello Melvyn,

Wednesday, July 16, 2003, 12:00:43 PM, you wrote:

MS> Hi again,


MS> Since PHP5 should also give a boost to PECL, I think there should be a way to
MS> extend a C-based class, somehow. I really don't favor the $this assignment as
MS> well, but what other option is there? Or is this specifick for the way the
MS> domxml module is setup, and people shouldn't write their classes like that?

I really can't follow you...it's all to weird.
anyway maybe you have a problem with the domxml class. Maybe you don't
understand oo at all, i don't know.

The one thing i can think of is that you try to overcome th oo principle of
'is-a' what is a bad idea. I think you need to use 'has-a' instead.

class bla {
prublic $dom;
function __construct() {
$dom = new ....
}
}

and then youse proxies. As i can read in your comments it seems you to lazy to
write the necessary proxies. Well we don't have aggregation any longer with
php5 and we don't have delegation at all. Maybe that is your real problem.

Hi Marcus,
Yep, that's exactly what I was trying to do. A shame you feel it's a bad idea,
as it allows code to remain dynamic.
Lazyness is one motivation I won't deny. Another is excessive code - it seems
like a complete waste to me. A third is, it won't be forwards compatible. I
will have to sync the proxies, with whatever methods are added/changed on the
original object.

Hello Melvyn,

Wednesday, July 16, 2003, 12:44:32 PM, you wrote:

MS> Hi Marcus,

MS> On Wednesday 16 July 2003 12:14, Marcus Börger wrote:
MS> There are surely things I don't understand, but this isn't one of them.
MS> Yep, that's exactly what I was trying to do. A shame you feel it's a bad idea,
MS> as it allows code to remain dynamic.
MS> Lazyness is one motivation I won't deny. Another is excessive code - it seems
MS> like a complete waste to me. A third is, it won't be forwards compatible. I
MS> will have to sync the proxies, with whatever methods are added/changed on the
MS> original object.

In this case:
a) Overcoming 'is-a' is no option at all.
b) Propably we have to discuss aggregation/delegation once again. Feel free to
do a RFC on those.

call_user_func(array('class','method'), $args);

Should work.

[...]
As Marcus already replied on this part and as I agree, I'll leave out
any comments:)
This is already supported (in PHP4). Simply use array("class", "method")
for the first argument instead of array($instance, "method").

thekid@friebes:~ > php -r 'class Foo { function bar($arg) {
var_dump($arg, $this); echo "--\n"; }} call_user_func(array("Foo",
"bar"), "static"); call_user_func(array(new Foo(), "bar"),
"non-static");'

string(6) "static"
NULL