Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98636
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.86 cause and error)
Reply-To: internals@lists.php.net
References: <CAF+90c9vdsLuh1GAB4VPbYzJp=XiH6a5w79t5Kt=JLV6=xkdDA@mail.gmail.com>
 <16.06.40046.20A35D85@pb1.pair.com>
 <CAFMT4Nrx-xUhy5dErAr-tY0dG5fE-H93n8Zxs_XYDPZq1MWGZw@mail.gmail.com>
 <CAF+90c_rz+kpgGEMn14vuxft7QNEpG611+gya6Jnv2dgoUBPMw@mail.gmail.com>
 <CAFMT4NoPS1vCQujZ_JSeP2aUeD6aN1XxgG-TFXfVBi2PdyqyWA@mail.gmail.com>
 <CAF+90c_bCzOjD_CoHdYOtVyWwpUe-YVu2gSzbJMRNwXoKJqV1Q@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
Message-ID: <b2b84857-1e30-9903-2f96-6298197d0268@fleshgrinder.com>
Date: Sat, 25 Mar 2017 14:37:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c_bCzOjD_CoHdYOtVyWwpUe-YVu2gSzbJMRNwXoKJqV1Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: TOKEN_AS_OBJECT for token_get_all()
From: php@fleshgrinder.com (Fleshgrinder)

On 3/25/2017 1:18 PM, Nikita Popov wrote:
> Overall, I must say that this thread has left me rather disappointed. I was
> harboring the misguided hope that it might be possible to introduce a
> simple, self-contained improvement, that resolves a major ergonomics pain
> point in ext/tokenizer, while also improving performance and memory usage.
> Essentially, a win on all fronts. What I get instead is a continued
> escalation of this simple change, first into the addition of a new function
> (which I disagree with, but which is still a feasible suggestion), then
> into the addition of a complex object-oriented system involving three
> classes, at least six methods, iterators and even managing to involve the
> question of namespaced core functionality, a well known and extensively
> discussed unresolved question! What am I supposed to do with such
> suggestions? I will obviously not waste my time discussing the design of
> such a system, let alone implementing it in its glorious complexity.
> 
> This is the point where I abandon this particular idea, as clearly my
> expectations of the scope of this change do not line up with those of
> others. I really wish people could get their priorities straight.
> 
> Nikita
> 

I think the general problem is that PHP is developing in all directions.
One of them is the "high-level language with low-level primitives"
direction that we have on the procedural side (yours), and the
"high-level language with high-level abstractions" direction that we
have on the OO/functional side (mine).

The approach you would like to take might be more pragmatic, and yield a
result faster. However, it is yet just another function where people are
required to first consult the documentation to actually find what is
possible to do. Especially if the flags keep on piling up. The returned
value is also always different, hence, every time one encounters this
function again she must go back to the documentation to check what it is
actually returning in this particular call. Just have a look once again
at the various highly complex return type combinations you just posted.

Continuing on the road of cheap wins, or getting features in fast to
solve some pain points (which you definitely are addressing here, no
argument there), directly translates to continuing on the road of no
coherent design of the overall language; in other words keeping it
C-like procedural. Whereas at the same time we have a HUGE shift towards
OO and functional in PHP since many years.

The things you are addressing with a combinatorial explosion is exactly
why I was proposing a proper OO design which addresses multiple issues:

- Easy exploration of possibilities via code completion (#no-doc).
- Clear separation of concerns.
- Naming that aids findability and comprehensibility.
- Dependency inversion and injection possibilities.
- Extension and forward compatibility is easy without breaking anything.
- Clear simple, single return types.

I understand your frustration, but I must keep my priorities straight.
Even if that means that I piss off one of the most important PHP
contributors. ?

PS: Please remember that I clearly stated that `fromFile` and the
iterator support can be added at a later stage. The same would be true
for any other additional functionality besides the one you are proposing.

**TL;DR** My priorities are straight: PHP is a high-level not low-level
language (some parties most definitely disagree here with me) and should
offer easy to understand, beginner friendly abstractions that are hard
to use incorrectly. The proposed change is the opposite and closer to C
than to a high-level language.

-- 
Richard "Fleshgrinder" Fussenegger