Hi Pierre, On Thu, Aug 4, 2016 at 1:23 PM, Pierre Joye <pierre....@gmail.com> wrote: > > Thanks for this proposal :) > > Some comments: > > Exceptions are not exceptional in this case but if there are invalid > options or arguments but everything else is expected to succeed or > fail. So I am not in favor to have exception here.
Sounds good to me. I'll modify them. > > Naming must have filter_ prefix This one is tough. I agree that it should have "filter_" prefix. However, I cannot come up with better names that aren't too long. Any suggestions? Anyone? > > We do have array filters, validate or filtering functions already I am > not sure why we need another function to do very similar things. Most > if not all ext/filter users (libraries, components, frameworks) > implements their own userfriendly interfaces (classes) and use the > existing filter APIs. The developers I talked to prefer to have simple > functions but fast, high quality and safe rather than complex APIs for > a specific flow, which is most likely won't match their needs. Most of > these higher level APIs are also using different approaches and OO > based, which simplifies a lot their usage. Those who are using full featured framework may ignore Filter module at all. My current objective is to make PHP ready/useful/easy for micro services, very simple web apps. As I wrote in the RFC, it's very hard validate things with current Filter module. It should be simpler for simple apps. One good thing about PHP is "It does not require complex framework/external libs to write simple app". Sadly, this has been changed due to security concerns. Most of recent my proposals are for "fast/secure/easy micro services" mostly with plain PHP, and keep "It does not require complex framework/external libs to write simple app" :) I understand your point view. My view is just different one. Thank you for the comment! Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
