Hallo,
Firstly thanks for the comments. In regards to storing
caller_scope in
op_array: the arguments against this make perfect sense. I am still
figuring out all of the nuances of the zend engine...so, equate it to
rookie mistake :P.
I've tried rewriting the patch to use zend_execute_data to store the
caller_scope pointer. However I have noticed something that could
prevent me from usint that struct to store the data. If any
function are
ran outside of the execute() function the
executor_globals.current_execute_data is never set. This is the
case for
register_shutdown_function(array('class', 'function')),
class::__destruct() (when called implicitly) and ob_start(array
('class',
'function')). So, short of tracking down all those instances and
creating a special zend_execute_data for them, I don't think it'll do
the trick unless I am just missing something. I am looking around
now to
see if there is anywhere else to store the data that makes sense.
In regards to naming: 'static' wasn't my first choice either. In
fact I
was originally using 'this::' due to me misreading the notes from the
PDM.
static DOES have some very clear cut advantages. Due to static
already
being a keyword there 0% likelihood that anyone is using it for a
class
name. Whereas with caller::foo, class::foo, owner::foo, (even
this::foo
I think) there is a chance (in some cases good, in other cases slim)
that someone has a class somewhere in their code named this. Which
imo
has more of a chance at breaking someones code than changing self's
behaviour would. (I doubt very strongly that anyone 'relies' on
early
binding for static functions...I could be wrong though.) I think
if we
can implement the change while ensuring that it is fully BC that
would
be the best route to go. Now, that all being said, if it is
decided to
use something other than 'static::' it is very easy to change.
ds-
On Thu, 2006-03-02 at 16:27 +0100, Lukas Smith wrote:
> Derick Rethans wrote:
> > On Thu, 2 Mar 2006, Jeff Moore wrote:
> >
> >> Unfortunately, the problem with making self late binding is
that that there
> >> are potential BC breaks. Is that possibility on the table?
> >
> > I don't think we should break any BC over this.
>
> Neither do I.
>
> regards,
> Lukas
>
>
