On Thu, Feb 13, 2020 at 3:48 AM Nikita Popov <nikita....@gmail.com> wrote:
> 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. > > Yep. I remember bringing this up in 2016 and there was generally good reception to it from you, Andrea, Stas, and Stig at the very least. Why isn't it in? It got derailed by some bike shed colorizing and a little bit of workplace drama then dropped on the floor. Thanks for picking it up, and I agree with your response to Larry. As nice as it would be to lazy iterate, the scanner is just in NO shape to tolerate reentering userspace and potentially reinvoking the scanner before the first run through is done. I also agree that being able to subclass the token would be great, but that PDO made some mistakes here and we can do that as a separate addition later on if there's not consensus now. I'm +1 for NOT overloading the token_get_all() function, but rather putting a static factory method on the PhpToken class (or whatever you call it). When we add subclassability, we can always add additional statics if our initial signature doesn't work out. I'm not clear why you want to final the base constructor. IMO we populate the fields on object creation, then invoke constructor (which is a no-op in the base class). Later uses of subclassing can deal with the properties (or not) at that time, in their own constructor, delegating (or not) to the base. TL;DR +1, because I wanted this four years ago. :) -Sara
