On 04/25/2016 02:28 PM, Joe Watkins wrote:
Morning internals,
This morning I attempted to prototype a dbc extension.
In my opinion, the patch, or internals, are not fit for the
intended purpose.
At the moment, the *only* way to perform meta programming is going
to be in userland. This is going to make it prohibitively slow, and
rather pointless.
why? It's quite easy to use attributes in C extension.
if (op_array->attributes) {
zval *val = zend_hash_find_str(op_array->attributes, "requires",
sizeof("requires")-1_;
if (val && Z_TYPE_P(val) == IS_ARRAY) {
HashTable *ht = Z_ARRVAL_P(val);
ZEND_HASH_FORECH_VAL(ht, val) {
...
ZEND_HASH_FOREACH_END();
}
}
None of the compiler API is exported: This means that AST is
almost useless to internals unless it's a constant expression.
Do you mean C or PHP API?
What exactly do you like to be exported? zend_compile_expr()? It's not a
problem to export it in 7.1.
There is a problem with zend extensions and fcall handlers, which
we are not sure how to fix.
This is completely unrelated historical problem :)
Working with AST is easy, working with opcodes directly is not.
Before we can have this, we must work on the AST API and allow
extensions to transform AST with much better hooks than we have at the
moment.
This is related to user extendable parser, that is definitely not a
subject of this RFC.
I was excited to start working with this .. at the moment, I'm -1.
I got you.
Attributes are not especially for DbC and user extendable parser, and
they are not a magic wand.
They may be an underlying layer for many things (including DbC).
But to reach what you want, you'll have to start from something anyway.
Thanks. Dmitry.
Cheers
Joe
PS. If anyone is interested http://github.com/krakjoe/dbc was my first
attempt at interacting with the patch.
On Mon, Apr 25, 2016 at 11:08 AM, Dmitry Stogov <dmi...@zend.com
<mailto:dmi...@zend.com>> wrote:
On 04/25/2016 12:44 PM, Pierre Joye wrote:
hi Dmitry,
Awesome work! Thanks.
I do like you keep what was discussed last time. Make the basics
available and leave the rest to the applications (doctrine or
other).
I feel too that how the apps will interact with may need some more
discussions but other commented on it so I won't interfer here :).
I've collected the most interesting feedback at
https://wiki.php.net/rfc/attributes#open_issues
And I'm going to correct RFC and implementation rethinking these
questions.
Thanks. Dmitry.
On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov
<dmi...@zend.com <mailto:dmi...@zend.com>> wrote:
The proposed by you "@..." syntax just won't fit into PHP
grammar, because @
used as silence operator.
Attribute, syntax is taken from HHVM. I don't see a big
reason to introduce
more fragmentation into PHP world.
Also see https://docs.hhvm.com/hack/attributes/syntax and I fully
agree with Dmitry here. It makes no sense now to go with our own
syntax.
If any of the hhvm developers are around, we may get some
feedbacks
about their current APIs (using getAttributes) and if they
would like
to change one thing or another. That could (or must) part of
the PHP
specifications.
Cheers,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
