Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Drupal 8.x is adopting PHP 5.4, and plans to start using PHP "Traits" in addition to classes and interfaces:
http://php.net/manual/en/language.oop5.traits.php
The Grammar Parser needs to support traits, so that the API module can support them and display properly on api.drupal.org.
Comment | File | Size | Author |
---|---|---|---|
#1 | 2206987-support-traits.patch | 6.75 KB | jhodgdon |
Comments
Comment #1
jhodgdonHere's a patch. It seems to work with the API module at least. It basically makes Traits work the same as Classes and Interfaces, since they're basically the same thing (but without implements and extends statements).
Comment #2
jhodgdonJust a note: The above patch is working fine in the API module for the Trait declarations.
However, the PHP use statements for Traits are not like use statements for classes. See http://php.net/manual/en/language.oop5.traits.php -- they are inside the {} of either classes or traits, and can have several variations:
a)
b)
c)
I think the current Grammar Parser code handles (a) or (b), but it doesn't handle (c). In current Core code in D8, there are no instances of (c)... I think maybe we can ignore it, at least for now, but I'm just putting it here as a point of interest.
Comment #3
jhodgdonOK, I have a final patch up on #2206991: Support Traits in API module. It includes some sample code and new tests. It works great with this patch for Grammar Parser, and all of the tests pass. I have not had to make any changes to the Grammar parser patch here, and I don't think we need to support the complicated use statement illustrated in my previous patch, at least not yet for practical purposes.
I'm going to venture to mark this RTBC... any chance we could get it committed and possibly get a new release of Grammar Parser? Thanks!
Comment #4
jhodgdonIs there any chance we could get this committed to Grammar Parser 2.x sometime soon? I'd like to deploy on api.drupal.org sometime in the next couple of weeks, and we need at least a dev version in order to do that. Thanks!
Comment #5
jhodgdonWell, I've run into a problem.
A recent commit to Drupal 8 has added a new form of a trait use statement (see comment #2 above).
And it's getting a fatal error. There's a call to:
PGPUse->aliasesToArray() on /home/jhodgdon/gitrepos/api7/parser.inc:509
And it results in:
Fatal error: Call to a member function toString() on a non-object in /home/jhodgdon/gitrepos/grammar_parser2/engine/object.inc on line 4231
The problem is most likely coming from this use statement in the current core/modules/forum/src/ForumManager.php file in Drupal 8:
Back to the drawing board... we'll apparently need to support that style of
use
usage.Comment #6
jhodgdonComment #7
jhodgdonapparently solotandem is working on fixing this.
Comment #8
solotandem CreditAttribution: solotandem commentedJennifer, thanks for encouraging me to get this done.
Add support for trait statement block in this commit.
I consider this issue simply about support for the trait block and simple use statements that might exist in it or a class. This is a very simple change as you can confirm; just a matter of adding references to the T_TRAIT token in several places.
Support for the alias and conflict resolution statements in the use body is another matter altogether. This was added in this commit. I did not make an issue for it.
Please review this commit to see if it provides information needed for API module regarding the aliases and conflict resolutions.
Changes from your patch include:
editor.inc
find() is essentially deprecated (the 2nd line returns NULL) so no point to update
parser.inc
did not remove comments on $interfaces and $classes as they are unrelated to the patch
do not add a constant definition for a PHP built-in constant
- if T_TRAIT is not defined in the PHP you are running, then do not use this version of the parser
- at the least wrap it in "if not defined"
- constant value may change in the future
reader.inc
do not add T_TRAIT to list of return tokens as it can not have scope modifiers (public, private,etc.)
simplify (or reduce) the code to store the respective nodes now including traits
add support for T_TRAIT_C
Comment #9
jhodgdonThanks a lot! This seems to be working fine. I'm making some updates to the API module and will be making a patch on #2288799: Support fancier use statements for traits as soon as I've verified it's all working right. But the new parsing and the methods on Grammar parser seem to be working fine. The only problems now will be in my code. :)
Comment #10
jhodgdonYes, all of Core worked great. Thanks! I think we can just mark this fixed, since we've both tested it?