Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108574
MIME-Version: 1.0
References: <CAF+90c9TWvj9Podt3uCdf43SzwweLfjn1H3DbWnt+pSE5UKYSw@mail.gmail.com>
In-Reply-To: <CAF+90c9TWvj9Podt3uCdf43SzwweLfjn1H3DbWnt+pSE5UKYSw@mail.gmail.com>
Date: Fri, 14 Feb 2020 07:38:20 -0600
Message-ID: <CAESVnVoe68=AWByg_qV5XUcV9W1RqksB=pp_OkNjThDSqjA7Aw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007b5ccc059e8952b2"
Subject: Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode
From: pollita@php.net (Sara Golemon)

--0000000000007b5ccc059e8952b2
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 13, 2020 at 3:48 AM Nikita Popov <nikita.ppv@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

--0000000000007b5ccc059e8952b2--