Hello David,
to me it was excellent in the first place, too. But when i started
thinking about it and wrote some lines of coude i came to the result
that the code is no longer understandable.
marcus
Thursday, March 2, 2006, 8:17:22 PM, you wrote:
> this:: would be excellent, since $this also references the actual
> class that's calling, not the one that declares. Very good idea!
> +1
> - David
> Am 02.03.2006 um 20:14 schrieb Andi Gutmans:
>> What about this:: ? Too confusing?
>>
>> At 08:33 AM 3/2/2006, Mike Lively wrote:
>>> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
