Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72442
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAF+90c-x7zpf+2p2PveCvntUmOwFjNXA-pDLEoC5gGcfxWxcXQ@mail.gmail.com>
References: <CAMUwpuSKjqCd7A9+OHVPCAKvYUCZFZURD51CkCCybYKoeZ0ohQ@mail.gmail.com>
 <CAF+90c-x7zpf+2p2PveCvntUmOwFjNXA-pDLEoC5gGcfxWxcXQ@mail.gmail.com>
Date: Mon, 10 Feb 2014 16:38:21 +0100
Message-ID: <CAMUwpuRmOqHwChaEK9RyAK-BwnLC=9gJNzCnPjUx_6EZRaED_A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] token_get_all() new API
From: jpauli@php.net (Julien Pauli)

On Mon, Feb 10, 2014 at 4:29 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Mon, Feb 10, 2014 at 3:54 PM, Julien Pauli <jpauli@php.net> wrote:
>>
>> Hi all,
>>
>> I recently worked on token_get_all() implementation to add an extra
>> argument to the function to show token names directly in the output
>> instead of having to call token_name() on every output (usually what
>> is done nowadays).
>>
>> I also added a flag so that the parsed scanner value can become
>> optionnal in the output, as sometimes one just wants a token stream
>> and is not interested in dealing with the scanner ouput.
>>
>> If you have ideas or thoughts ?
>>
>> https://github.com/jpauli/php-src/compare/token_names
>>
>> Julien.P
>
>
> Do you have some examples for practical uses of these modes? E.g. in what
> situation would you need only the token names, but not their content?

Well, having a token stream. T_A + T_B + T_C = something , I don't
care about those ';' and '}'.
They make parsing the array output of token_get_all() harder :-p

>
> What I don't like about this change is that it introduces an additional
> llist indirection, which presumably will have the function slower and more
> memory heavy.

Yes, I could use HashTable directly, that's a detail and can be
patched very quickly :-)

Julien