Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108755
MIME-Version: 1.0
References: <CAF+90c9TWvj9Podt3uCdf43SzwweLfjn1H3DbWnt+pSE5UKYSw@mail.gmail.com>
In-Reply-To: <CAF+90c9TWvj9Podt3uCdf43SzwweLfjn1H3DbWnt+pSE5UKYSw@mail.gmail.com>
Date: Tue, 25 Feb 2020 16:59:39 +0100
Message-ID: <CAF+90c_MShaa_-8Jtor6V6e8fJRfwxBLH67gJgmfA8BrqpiNWA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003df079059f689409"
Subject: Re: [RFC] token_get_all() TOKEN_AS_OBJECT mode
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000003df079059f689409
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 13, 2020 at 10:47 AM Nikita Popov <nikita.ppv@gmail.com> 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.
>

I think this proposal is in a pretty decent shape now, and I'd like to move
it to voting soon. The only remaining open question is whether we want to
add any additional predefined methods. As the class can now be extended,
every library can add their own methods, but there might still be value in
providing some things by default, primarily for performance reason. For
example, the proposed is() method can be a good bit more efficient when
implemented directly in extension code.

Any feedback on this point?

Nikita

--0000000000003df079059f689409--