Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98949
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ethome.sk from 92.240.253.144 cause and error)
Date: Wed, 3 May 2017 03:23:57 +0200
To: internals@lists.php.net
Message-ID: <20170503032357.69de58d8@eto-mona.office.smartweb.sk>
In-Reply-To: <CA+kxMuRc1E5_SfYdX3kmAf7s42KnU46B9k=u1aMfh0MdGD6y0Q@mail.gmail.com>
References: <20170427115041.06339340@eto-mona.office.smartweb.sk>
	<CA+kxMuTAECR8FM0NNGjwy=Ax3TSksiUUsJ6DtnnppTe9C5jbVw@mail.gmail.com>
	<20170428044910.01fc1d66@eto-mona.office.smartweb.sk>
	<CA+kxMuRc1E5_SfYdX3kmAf7s42KnU46B9k=u1aMfh0MdGD6y0Q@mail.gmail.com>
Reply-To: et.code@ethome.sk
Organization: ethome.sk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] concept: further improvement of filter
 extension, "generalising" filter definitons while adding new callback
 filter type
From: et.code@ethome.sk ("Martin \"eto\" Misuth")

On Fri, 28 Apr 2017 11:06:10 +0100
Dan Ackroyd <danack@basereality.com> wrote:

> 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.
Got it. So this is to minimize php team maintenaince burden. Makes sense.
 
> 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?
Understood. Still, from my point of view, filter is missing tiny nudges that
have to be done on module side. 

> > 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.
Thank you, I will investigate that suggestion as well.
 
> Well, that sounds like a real problem, but it's really not obvious how
> your RFC would solve that problem.
I believe, my approach provides scaffolding, that will allow filter to 
be extended later, to advance through definition arrays on it's own, 
without need to wrap initial "walk" of definition array, into userland
"iterators" (functions that unpack data from custom definition arrays 
and transform them into form suitable for filter consumption). 

> 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.

This might sound like void excuse, but I projected my personal experience
with new hires (who all left after very short time working with our codebase) 
onto you. After observing that several time, I came to understand, our
system is "shomehow weird" and needs thorough explanation. I had to explain 
the system again and again, and got caught up in this loop. I will refrain from
ever doing this again, from now on. 

> 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.

Can I interpret that paragraph this way:
- it's okay for me to take ext/filter with my modifications 
  (even though they modify only part of the extension) 
- and publish them somewhere else (like github for example)
- while refining the api further to be "perfect"
- while adding intended usecases and examples
- and only after that ask for evaluation by others and attempt RFC again

1. Correct?

If yes, there is one thing I don't know what to do about, and need your advice.

2. What about module name clash?

I would prefer, for this alternative module, to be named filter as well 
(as there is intent to get modifications back into core, eventually). 

Or it's should I go and rename thing to something like filteri ("filter
improved") or filtero ("filter other"), even though big parts of code are
original filter still? I would like to avoid doing that.

> cheers
> Dan
Thank you for your advice.

> 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.
Ah, well form pages are "static" (aka first client render). Form handlers
that actually deal with dynamic part of those forms, and are tied to "private"
user sessions. I fail to see, how can I reliably and securely cache those, if
they are unique per session, form and request.

  eto