[PHP-DEV] [RFC] [Discussion] JSON_THROW_ON_ERROR

[Andrea Faulds]

Hi everyone,

Craig Duncan previously sparked discussion here about JSON's 
error-handling behaviour. Unfortunately, his attempt to change it seems 
not to have gone anywhere, but I have his blessing to try this other 
approach instead.


So here's an RFC: https://wiki.php.net/rfc/json_throw_on_error

The feature can be described in a single paragraph (in fact, the title 
is pretty much enough, the patch is just detail) but it's better to go 
through the proper RFC process.


Please tell me what you think.

Thanks!

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Match expression

[Thomas Hruska]

On 9/9/2017 5:18 AM, Dan Ackroyd wrote:

for when you forget to put break.


Applying break statements is the first thing you should do if you intend 
to break.  That way it can't be forgotten.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Operator functions

[Nikita Popov]

On Fri, Sep 8, 2017 at 11:41 PM, Andrea Faulds  wrote:

> Hi everyone!
>
> Here's an RFC for a small, simple, self-contained feature with no
> backwards-compatibility breaks and which in fact doesn't even touch the
> language's syntax (it's 50%+1 eligible!) but which could make PHP a bit
> more expressive and consistent, especially with potential later features.
> It even has a test designed to impose minimal maintenance burden while
> testing a fairly large possibility space!
>
> Anyway, the RFC in question is this: https://wiki.php.net/rfc/opera
> tor_functions
>
> Please tell me what you think and suggest any potential improvements or
> anything you think might have been an omission.
>
> Thanks!


I like the general idea here, but have some comments.

My main observation is that this proposal is only really useful in
combination with a form of partial application. Passing operators to
array_reduce() is cute, but it's not a major application, especially as we
already have built-in functions for the two common operations (array_sum
and array_product).

Where operators-as-functions really shine is in cases where only one of the
operands is bound. You acknowledge this in the RFC, and provide a few
examples using a (not yet existing) partialApply() function:

// Select only the positive numbers
$positiveSubset = array_filters($numbers, partialApply('>', 0));

However, this code is subtly broken. Partial application (at least without
specifying a more specific behavior) operates from left to right, so this
code would be equivalent to:

// Select only the positive numbers
$positiveSubset = array_filters($numbers, function($n) { return 0 > $n;
});

As such, it would return all negative numbers, not all positive numbers.

This is a general issue of partial application in combination with
operators: For the operations that do not commute, you nearly always want
to bind the right operand, not the left.

For my own purposes, I define an operator() function as follows:
https://github.com/nikic/iter/blob/master/src/iter.fn.php#L60

This function either accepts a single argument such as operator('+'), in
which case it is essentially equivalent to this proposal. Or it accepts two
arguments, in which case the right operand will be bound, such as
operator('>', 0).

I wonder if providing such a function might not be a better solution to
this problem. It also has the additional advantage that it can be easily
polyfilled in older PHP versions.

Nikita

Re: [PHP-DEV] Re: [RFC] Match expression

[Dan Ackroyd]

On 9 September 2017 at 12:21,   wrote:
> Hi everybody!
>
> Has this idea been discussed before?
> ..
> Each case has an implicit `break`

This part has come up before, as the default behaviour of fall through
is a nasty gotcha for when you forget to put break. I can't find the
conversation right now, but the discussion was around a 'select'
keyword. I think the conversation didn't proceed as it seemed like
adding a new keyword just to fix the fall-through behaviour was a bad
tradeoff.

This RFC idea adds more capabilities, so is a better trade-off, and
more likely to be worth doing in my opinion.

> One downside, since PHP doesn’t implicitly return the last statement
> as some languages do there’s no obvious way to do multi-statement cases.

People are still working on and hoping for short-closures. That RFC
and any potential one for this, should attempt to use the same syntax.


On 9 September 2017 at 13:11, Andreas Treichel  wrote:
> Something like:
>
> *wall_of_hard_to_read_code*

Yeah, that's a pretty good example of why I'd be in favour of this RFC.


cheers
Dan
Ack

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Match expression

[Andreas Treichel]

Hi,

Something like:

function match($x) {
switch(true) {
case $x === 1:
return 'Tiny';
case is_numeric($x) && $x <= 10:
return 'Small';
case is_numeric($x) && $x <= 20:
return 'Medium';
case is_numeric($x) && $x <= 30:
return 'Large';
case is_numeric($x) && ($x >= 31 || $x <= 100):
return 'Enormous';
case $x instanceof Foo:
case $x instanceof Bar:
return 'What?';
default:
return 'Unknown';
}
}

the problem is you need is_numeric because no type safe version of <= 
and >= exists.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] add Fiber (sackful coroutine) support

[Niklas Keller]

2017-09-09 8:07 GMT+02:00 Haitao Lv :

>
> > On 1 Sep 2017, at 22:25, Niklas Keller  wrote:
> >
> > A potential way around that (might be a stupid idea I just had): Allow
> > defining "wrappers" per file, that auto-wrap marked functions.
>
> Amp need these wrapper functions because we cannot yield a generator from
> its sub function call. So if we introduce fiber, these wrapper is needless.


We could easily support yielding generators and auto-wrapping them in the
coroutine implementation, but not every generator is a coroutine. And
generators are an implementation detail, it doesn't make sense to force
everything to be a generator.


>
> >
> > I don't see an event loop or promises being built-in soon, but something
> > like that could provide `async` with userland magic. Not the best thing,
> > but maybe better than preprocessing, don't know.
>
> Fiber is asymmetric coroutine, and the PHP kernel has no duty to schedule
> them. So a built-in event loop is no needed.


I'm actually thinking about bringing our promise + coroutine implementation
to php-src. `await` could be used to automatically convert generators into
coroutines, which implement promise. It would be mostly syntactic sugar for
the current Amp implementation, because all these wrappers are gone, but
the implementation details of something being a coroutine stays hidden
behind a promise interface.

Regards, Niklas

Re: [PHP-DEV] Re: [RFC] [Discussion] Operator functions

[ilija . tovilo]

I also love this idea!
This and short arrow functions and I’m golden (in terms of closures at least) :)

Regards


On 9 Sep 2017, 03:31 +0200, Tom Worster , wrote:
> On 8 Sep 2017, at 17:41, Andrea Faulds wrote:
>
> > Hi everyone!
> >
> > Here's an RFC for a small, simple, self-contained feature with no
> > backwards-compatibility breaks and which in fact doesn't even touch
> > the language's syntax (it's 50%+1 eligible!) but which could make PHP
> > a bit more expressive and consistent, especially with potential later
> > features. It even has a test designed to impose minimal maintenance
> > burden while testing a fairly large possibility space!
> >
> > Anyway, the RFC in question is this:
> > https://wiki.php.net/rfc/operator_functions
> >
> > Please tell me what you think and suggest any potential improvements
> > or anything you think might have been an omission.
>
> Yes!
>
> I have wanted this for many years. In the first programming language in
> which I achieved real proficiency, this was vernacular. It would make me
> happy to return to it in the language I now use most. An anonymous
> function that turns an operator into three lines looks dumb and makes me
> sad.
>
> Tom
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] A validator module for PHP7

[Tony Marston]

"Yasuo Ohgaki"  wrote in message 
news:caga2bxa4uvkl-zslab2bf05l4q_oduixszvvyzu9nddksvt...@mail.gmail.com...


Hi Tony,





As a person who has been developing database applications for several
decades and with PHP since 2003 I'd like to chip in with my 2 cent's 
worth.

Firstly I agree with Dan's statement:

This type of library should be done in PHP, not in C.

Secondly, there is absolutely no way that you can construct a standard
library which can execute all the possible validation rules that may 
exist.

In my not inconsiderable experience there are two types of validation:
1) Primary validation, where each field is validated against the column
specifications in the database to ensure that the value can be written to
that column without causing an error. For example this checks that a 
number

is a number, a data is a date, a required field is not null, etc.
2) Secondary validation, where additional validation/business rules are
applied such as comparing the values from several fields. For example, to
check that START_DATE is not later than END_DATE.

Primary validation is easy to automate. I have a separate class for each
database table, and each class contains an array of field specifications.
This is never written by hand as it is produced by my Data Dictionary 
which
imports data from the database schema then exports that data in the form 
of

table class files and table structure files. When data is sent to a table
class for inserting or updating in the database I have written a standard
validation procedure which takes two arrays - an array of field=value 
pairs

and a array of field=specifications - and then checks that each field
conforms to its specifications. This validation procedure is built into 
the

framework and executed automatically before any data is written to the
database, so requires absolutely no intervention by the developer.

Secondary validation cannot be automated, so it requires additional code
to be inserted into the relevant validation method. There are several of
these which are defined in my abstract table class and which are executed
automatically at a predetermined point in the processing cycle. These
methods are defined in the abstract class but are empty. If specific code
is required then the empty class can be copied from the abstract class to
the concrete class where it can be filled with the necessary code.

If there are any developers out there who are still writing code to
perform primary validation then you may learn something from my
implementation.

If there are any developers out there who think that secondary validation
can be automated I can only say "dream on".



Please let me explain rationale behind input validation at outermost trust
boundary. There are 3 reasons why I would like propose the validation. All 
of 3

requires validation at outermost trust boundary.

1. Security reasons
Input validation should be done with Fail Fast manner.


The language should only provide the basic features which allow values to be 
validated. That is what the filter functions are for. All that is necessary 
is for user input to be validated before any attempt is made to write it to 
the database.



2. Design by Contract (DbC or Contract Programming)
In order DbC to work, validations at outermost boundary is mandatory.
With DbC, all inputs are validated inside functions/methods to make sure
correct program executions.


Irrelevant. DbC is a methodology which PHP was never designed to support, 
and I see no reason why it should. If you really want DbC then switch to a 
language which supports it,  or use a third-party extension which provides 
supports.



However, almost all checks (in fact, all checks done by DbC support)
are disabled for production. How to make sure program works correctly?
All inputs data must be validated at outermost boundary when DbC is
disabled. Otherwise, DbC may not work. (DbC is supposed to achieve
both secure and efficient code execution.)



3. Native PHP Types
Although my validate module is designed not to do unwanted conversions,
but it converts basic types to PHP native types by default. (This can be
disabled) With this conversion at outermost trust boundary, native PHP type 
works

fluently.


What is the difference between a basic type and a PHP native type?


Although, my current primary goal is 1, but 2 and 3 is important as well.

2 is important especially. Providing DbC without proper basic validation
feature does not make much sense, and could be disaster.
Users may validate input with their own validation library, but my guess
is pessimistic. User wouldn't do proper validation due to too loose
validation libraries and rules. There are too few validators that do
true validations that meet requirements for 1 and 2. IMHO, even if
there are good enough validators, PHP should provide usable validator
for core features. (DbC is not implemented, though)


It does, in the form of the filter functions.


I hope you understand my 

Re: [PHP-DEV] Don't add simple objects to GC's roots

[Haitao Lv]

> On 30 Jul 2017, at 18:19, Andreas Treichel  wrote:
> 
> Hi,
> 
>> So I propose to make the gc_disable function accept one zval reference as
>> parameter. And if gc_disable get that zval, gc_disable just drop the zval’s
>> GC_COLLECTABLE flag, which will hint the PHP gc not to trace that zval.
> 
> i dont know if this is a good idea or not. But for the "s" in solid, create a 
> new function like gc_exclude to exclude variables from the garbage collector 
> and do not add a parameter to gc_disable.

A new function gc_hint($zval, bool $collectable) has been introduced at 

https://github.com/php/php-src/pull/2665/files
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] add Fiber (sackful coroutine) support

[zixu mo]

the best corotine . must be golang go and chan. very easy to use. non blocking. 




On Sat, Sep 9, 2017 at 2:28 PM +0800, "Haitao Lv"  wrote:











> On 2 Sep 2017, at 20:19, Rowan Collins  wrote:
> 
> On 1 September 2017 14:02:29 BST, Haitao Lv  wrote:
>> 
>> Fiber is a lightweight thread. Please see
>> https://en.wikipedia.org/wiki/Fiber_(computer_science)
>> And ruby support Fiber. Please see
>> https://ruby-doc.org/core-2.4.1/Fiber.html
> 
> Ah, thanks, that makes more sense now.
> 
> I note that the examples there all implement it not as a keyword, but as a 
> library function, which maybe makes more sense: whereas "yield" turns a 
> function declaration into a generator declaration, "Fiber\yield", as we might 
> call it, is just a function call which can happen anywhere and manipulates 
> some global state.

As the Zend Engine does not offer API to pause execution, I cannot implement 
the await without
introducing a new keyword (just like yield).

> The choice of "await" also feels odd: you're not awaiting the thing on the 
> right-hand side of the keyword, you're sending it somewhere and awaiting 
> something else.

await is chosen because we cannot reuse the `yield` keyword. Maybe we can 
choose a more proper keyword.

>> You can see the await as a resumable return. The value after it
>> will be returned and the function
>> will be paused.
> 
> Again, this explanation doesn't make sense if you can call foo() without any 
> Fiber code. If there isn't an active Fiber to pause, the "await" line can't 
> "return" anything; it will presumably throw an error of some sort.
> 
> function foo($x) {
> $y = Fiber\yield($x);
> return $x + $y;
> }
> echo foo(1);
> 
> The 1 isn't "returned" to the echo, it's passed off to a global function for 
> further processing. This makes much more sense to me than implying that foo() 
> is no longer a normal function.

await is not yield. It need a separate vm stack to work. So call the foo 
function without a Fiber will
throw a runtime error exception.

> 
>>> Your ->resume() doesn't seem to do anything a normal generator can't,
>> except that the yield is nested deeper.
>> 
>> The await is a nested deeper yield!
> 
> Yes, I understand that, but that seems to be completely unrelated to the API 
> design of having resume() act as start, continue, and final result all rolled 
> into one. As I say, I didn't entirely follow the reasoning for allowing 
> return in generators, but if Fibers are used for the same purpose, I would 
> expect the same concerns to arise.
> 
> However, I think the comparison to generators may be more distracting than 
> useful, as they seem to be very different solutions to the same or related 
> problems.

If fiber were implemented, the generator would be a special fiber.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] add Fiber (sackful coroutine) support

[Haitao Lv]

> On 2 Sep 2017, at 20:19, Rowan Collins  wrote:
> 
> On 1 September 2017 14:02:29 BST, Haitao Lv  wrote:
>> 
>> Fiber is a lightweight thread. Please see
>> https://en.wikipedia.org/wiki/Fiber_(computer_science)
>> And ruby support Fiber. Please see
>> https://ruby-doc.org/core-2.4.1/Fiber.html
> 
> Ah, thanks, that makes more sense now.
> 
> I note that the examples there all implement it not as a keyword, but as a 
> library function, which maybe makes more sense: whereas "yield" turns a 
> function declaration into a generator declaration, "Fiber\yield", as we might 
> call it, is just a function call which can happen anywhere and manipulates 
> some global state.

As the Zend Engine does not offer API to pause execution, I cannot implement 
the await without
introducing a new keyword (just like yield).

> The choice of "await" also feels odd: you're not awaiting the thing on the 
> right-hand side of the keyword, you're sending it somewhere and awaiting 
> something else.

await is chosen because we cannot reuse the `yield` keyword. Maybe we can 
choose a more proper keyword.

>> You can see the await as a resumable return. The value after it
>> will be returned and the function
>> will be paused.
> 
> Again, this explanation doesn't make sense if you can call foo() without any 
> Fiber code. If there isn't an active Fiber to pause, the "await" line can't 
> "return" anything; it will presumably throw an error of some sort.
> 
> function foo($x) {
> $y = Fiber\yield($x);
> return $x + $y;
> }
> echo foo(1);
> 
> The 1 isn't "returned" to the echo, it's passed off to a global function for 
> further processing. This makes much more sense to me than implying that foo() 
> is no longer a normal function.

await is not yield. It need a separate vm stack to work. So call the foo 
function without a Fiber will
throw a runtime error exception.

> 
>>> Your ->resume() doesn't seem to do anything a normal generator can't,
>> except that the yield is nested deeper.
>> 
>> The await is a nested deeper yield!
> 
> Yes, I understand that, but that seems to be completely unrelated to the API 
> design of having resume() act as start, continue, and final result all rolled 
> into one. As I say, I didn't entirely follow the reasoning for allowing 
> return in generators, but if Fibers are used for the same purpose, I would 
> expect the same concerns to arise.
> 
> However, I think the comparison to generators may be more distracting than 
> useful, as they seem to be very different solutions to the same or related 
> problems.

If fiber were implemented, the generator would be a special fiber.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] add Fiber (sackful coroutine) support

[Haitao Lv]

> On 1 Sep 2017, at 22:25, Niklas Keller  wrote:
> 
> A potential way around that (might be a stupid idea I just had): Allow
> defining "wrappers" per file, that auto-wrap marked functions.

Amp need these wrapper functions because we cannot yield a generator from
its sub function call. So if we introduce fiber, these wrapper is needless.

> 
> I don't see an event loop or promises being built-in soon, but something
> like that could provide `async` with userland magic. Not the best thing,
> but maybe better than preprocessing, don't know.

Fiber is asymmetric coroutine, and the PHP kernel has no duty to schedule 
them. So a built-in event loop is no needed.



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php