On Thu, Feb 13, 2020, at 3:47 AM, Nikita Popov wrote: > Hi internals, > > This has been discussed a while ago already, now as a proper proposal: > https://wiki.php.net/rfc/token_as_object > > tl;dr is that it allows you to get token_get_all() output as an array of > PhpToken objects. This reduces memory usage, improves performance, makes > code more uniform and readable... What's not to like? > > An open question is whether (at least to start with) PhpToken should be > just a data container, or whether we want to add some helper methods to it. > If this generates too much bikeshed, I'll drop methods from the proposal. > > Regards, > Nikita
I love everything about this. 1) I would agree with Nicolas that a static constructor would be better. I don't know about polyfilling it, but it's definitely more self-descriptive. 2) I'm skeptical about the methods. I can see them being useful, but also being bikeshed material. For instance, if you're doing annotation parsing then docblocks are not ignorable. They're what you're actually looking for. Two possible additions, feel free to ignore if they're too complicated: 1) Should it return an array of token objects, or a lazy iterable? If I'm only interested in certain types (eg, doc strings, classes, etc.) then a lazy iterable would allow me to string some filter and map operations on to it and use even less memory overall, since the whole tree is not in memory at once. 2) Rather than provide bikesheddable methods, would it be feasible to take a queue from PDO and let users specify a subclass of PhpToken to fetch into? That way the properties are always there, but a user can attach whatever methods make sense for them. IMO the laziness would be more valuable, since a struct class can be operated on by an external function just as easily as a method, especially if using a functional pipeline. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
