Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98896
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 74.125.83.45 cause and error)
MIME-Version: 1.0
In-Reply-To: <20170428044910.01fc1d66@eto-mona.office.smartweb.sk>
References: <20170427115041.06339340@eto-mona.office.smartweb.sk>
 <CA+kxMuTAECR8FM0NNGjwy=Ax3TSksiUUsJ6DtnnppTe9C5jbVw@mail.gmail.com> <20170428044910.01fc1d66@eto-mona.office.smartweb.sk>
Date: Fri, 28 Apr 2017 11:06:10 +0100
Message-ID: <CA+kxMuRc1E5_SfYdX3kmAf7s42KnU46B9k=u1aMfh0MdGD6y0Q@mail.gmail.com>
To: et.code@ethome.sk
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] concept: further improvement of filter extension,
 "generalising" filter definitons while adding new callback filter type
From: danack@basereality.com (Dan Ackroyd)

On 28 April 2017 at 03:49, Martin "eto" Misuth <et.code@ethome.sk> wrote:

> would make maintaining such library much easier

No. Maintaining stuff in PHP core is much more difficult than
maintaining it in userland. 'Maintaining' doesn't just mean fixing
bugs, it includes thinking about how any changes to APIs get rolled
out to users, while minimising BC problems, and keeping code
up-to-date with the PHP engine.

These things are much easier to do in userland than they are in PHP core.

> It would be immensely valuable to me, if we could have filter extension
> just intelligent enough, that it would process all request data
> according to template, from each input source in succession, **on it's own**,
> **in one go**

While I can see that could be useful to you the question, again, is
why can't this be done in userland?

> Even if I store "form definition" arrays in some memory cache (I tried apcu
> and ramdisk), so that their instantiation is relatively quick,

If you want data/code to be retrieved very quickly, I'd recommend
generating PHP code, and then letting OPCache, cache that code, as
well as possibly use a classloader that is a good fit for your use
case, like this one: https://github.com/Danack/LowMemoryClassloader/
rather than a generic classloader. It loads classes that are already
present in OPCache with zero system calls.


> that we are
> constantly marshalling and unmarshalling things from definition arrays

Well, that sounds like a real problem, but it's really not obvious how
your RFC would solve that problem.

> I hope you are still here.

To be honest, I kind of faded out in the middle, but I'm back now.

You might want to consider the phrase "I'm sorry I wrote you such a
long letter; I didn't have time to write a short one". This list is
distributed to thousands of people. Spending some time editing your
email down to a concise one, makes it much more likely to be read.

Also, it's disappointing that you wrote so many words, but didn't
(imho) actually answer why this needs to be in core rather than a
userland library. Even if other people might find it useful, that can
be more easily done through distributing userland code i.e. through
packagist.

If it _really_ can't be done in userland, then possibly writing it as
a PECL extension would be a good way to prove that it is a useful
thing that other people would want to use, as well as being a good way
of iterating the API until it fits everyone's use-cases, rather than
hoping to get the API correct on the first version in PHP core.

cheers
Dan

p.s.

> I am reminding this is happening on "ouput" side of things, where there is no
> reason to burn cycles in generating markup, unless form is completely validated
> (for confirmation display).

It's hard to know for sure, without seeing your actual code, but this
also sounds like a problem that varnish cache, with edge side includes
is designed solve.