Hi Marcus,
> And I could say that what the two of you designed ofr PHP is not a design
> but a very confusing incoherent implementation that is based on the lack
> of being able to get support for something else in the underlying c
> implementation.
Huh? The current implementation is by design, not because of any
limitations on C level. If you are refering to the following sentence in
your answer to Stanislav:
> If this really was to be bound to a $this at the creation, then we'd put it
> into the scope binding list and not have it be handled implicitly. But then
> we cannot do that with the current c level api.
The fact is: We could very easily. We decided against it (it's somewhere in
the internals archives from over half a year ago, I'm too lazy to look for
it).
So, if I get you, you say: "If $this is only bound at closure creation time,
then you should add $this to use()", i.e.:
$f = function () use ($this) { ... };
Well, if you rather want that syntax instead of static/non-static, you
could simple edit zend_compile.c and do the following:
- change zend_do_begin_lambda_function_declaration: set fn_flags to
ZEND_ACC_STATIC by default (and remove the is_static parameter
from that function)
- change zend_do_fetch_lexical_variable: In the case $this was
specified as a lexical variable, remove the ZEND_ACC_STATIC flag
from the function flags and return immediately (and remove the
current error message)
- remove the T_STATIC from the grammar definition in zend_lang*.y
Unified diff of that should be max. 100 lines long.
So, this is NOT a limitation on the C level, this is a deliberate
design decision. And, btw., it is not a design decision I care about
very much - if there's a majority to change it, I've no problem with
that.
> You took somethign very special and made it behave somewhat
> different making it even more specific and different from anyone's
> expectations, excluding people that understand the underlying c level
> issues.
No, we did not do any such thing. People who do a lot of Javascript
expect the behaviour you describe (i.e. re-binding), but that does
not necessarily mean everybody does. And if you read postings made by
beginners with Javascript in beginners' web forums or beginners'
mailing lists, the re-binding of the this variable is a VERY confusing
thing for beginners and not natural at all. You may have grown
accustomed to this behaviour, but please do not make the mistake of
thinking that your expectations are the expectations of the rest of
the world. I do acknowledge that some people like you will expect
this behaviour due to their background in Javscript.
I also posted in HUGE DETAIL why I find your approach to be *very*
problematic. I also went into detail on why you find your approach
more natural and why Javascript is different than PHP in this aspect
so you can't simply copy the concept from one to another. I also
added a proposal which contains an alternative that may not be ideal
but may satisfy all the needs. But instead of really replying to
that, you simply took the first sentence, used my admittedly not
very ideal wording as polemic and repeated your statement from
before. I don't think this will get us anywhere.
So, I would be very happy if you could 1) acknowledge that what you
would expect is not necessarily that what everybody else would
expect (some others certainly, but not everybody), 2) realize that
many (albeit not all) things in the current implementation are NOT
there because of C limitations but are deliberate (see above for an
example) and 3) have another look at my previous posting, think
about it for some time and THEN reply to it. Because the intention
behind my posting was NOT to say "you're wrong, you ..." but rather
to say "I get where you are coming from but have a look at this
example, your proposal will cause additional problems. And your
expectations do not necessarily match mine. But I don't want to
dismiss your idea completely, so here's an alternative idea that
came to my mind, please think about it."
Regards,
Christian
PS: By the way, Python does not rebind closures that enclose the
current object handle either:
class Foo:
def __init__ (self, v):
self.v = v
def getClosure (self):
def closure (w):
return self.v + w
return closure
o1 = Foo (2)
o2 = Foo (3)
# both are o1.getClosure not o2!
o1.xyz = o1.getClosure()
o2.xyz = o1.getClosure()
print o1.xyz (2) # 4
print o2.xyz (2) # 4
(Yes, that's due to the different concept of the 'self' variable
in Python compared to the way PHP and Javascript use $this, but it
just demonstrates that one has to look at the other concepts that
are implemented in the language in order to get something
consistent. That's precisely my argument for PHP, too.)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
