$this assignment and call_user_func question

Hi,

I've heard rumors that there are plans to take away the ability to
assign to $this in php 5. If this is true, I would like to place a vote
to keep it, as it can be very useful in conjunction with
__call()/__get()/__set() to implement run-time aggregation seamlessly

In addition, will call_user_func() support static methods before 1.0?
call_user_func('class::method', $args);

Regards,
Greg

phpDocumentor
http://www.phpdoc.org

Hi Marcus,

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

Hi again,

[ ... ]

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...

Which returns a domxml object, without method 'foo'.

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.

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?

So
you are missing the possibility to exchange the contants of a dom clas,
that's all you do this tricky stuff for?

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?

--
Melvyn

Hi Marcus,

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.

There are surely things I don't understand, but this isn't one of them.

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

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.

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.

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.

--
Melvyn