On 2019-10-14 05:46, Nikita Popov wrote:
> This should be fixed with
> https://github.com/php/php-src/commit/c518932c0326a938f0fd0254f2adb03b1cddfbca.
> Now using just
>
> ./configure --disable-all --with-openssl OPENSSL_LIBS="-l:libssl.a
> -l:libcrypto.a -ldl -pthread"
>
> works for me.
Hmm, I
On 2019-10-14 07:01, Rainer Jung wrote:
> Could you do yet another test? First manipulate the configure script with the
> following two commands:
>
> cp -p configure configure.saved
>
> # the following is one long line
>
> sed -e 's#PKG_CONFIG --libs openssl#PKG_CONFIG --libs --static
Hi Mike
I think your hypothetical PHP syntax won't happen. Not because it's bad
idea but because PHP just simply can't. I understand that you came up with
that idea from Golang background but the reason Golang can do that because
in Golang, assignments are statement not expression. Even `++` or
On 21/10/2019 21:18, Mike Schinkel wrote:
But to follow up to clarify what I was thinking consider the
following/ (hypothetical) /PHP syntax. Note that the return value
has two comma separated values, and the assignment can accept
those multiple values into two comma separated
On 21/10/2019 21:38, Benjamin Morel wrote:
Sure, you can do without exceptions. I think what you're suggesting is
similar to Go's error handling. But PHP at some point decided in
favour of exceptions, so it would be logical to pursue in that direction.
I didn't say "do without exceptions", I
> On Oct 21, 2019, at 4:38 PM, Benjamin Morel wrote:
> Sure, you can do without exceptions. I think what you're suggesting is
> similar to Go's error handling.
Yes, it is like Go's error handling.
> But PHP at some point decided in favour of
> exceptions, so it would be logical to pursue in
> On Oct 20, 2019, at 11:11 PM, Kosit Supanyo wrote:
> Ok, so let's look at a scenario. Will we be able to do this in the future, if
> we decide to allow multiple expressions to result in a final value?
> $y = switch ($x) {
> case 1 => $arr = get_array(), array_pop($arr),
> case -1 =>
>
> I think this argument is something of a logical fallacy: just because
> exceptions are (or can be) more fine-grained than the current return
> value, that doesn't mean they're the best tool for the job.
> If I'm remembering it correctly, an example is the old PEAR
> error-handling model, where
> On Oct 21, 2019, at 4:51 AM, Rowan Tommins wrote:
>
> On Sun, 20 Oct 2019 at 22:35, Mike Schinkel wrote:
>> I would much prefer to use a switch for multiple, mutually exclusive cases
>> no matter what how complex the expression is because with a switch the
>> cases expressions line up
> On Oct 21, 2019, at 11:12 AM, Rowan Tommins wrote:
>> What if in the future PHP implements variadic syntax for assigning to
>> arrays, e.g. $var = 1,2,3 where $var could satisfy a $variadic parameter
>> set of parameters w/o requiring `...`? If PHP embraces that — note GoLang
>> has something
On Mon, Oct 21, 2019 at 11:29 AM Nikita Popov wrote:
> This is a fairly common deficiency in the implementation of internal
> functions. Part of the reason is that historically zend_parse_parameters
> did not support the ! modifier for integers, and partly these are just
> implementation
On 21/10/2019 18:45, Benjamin Morel wrote:
I personally like exceptions in all cases, as they allow for
fine-grained error handling, for example:
```
try {
mkdir('somedir');
} catch (FileExistsException $e) {
// only catch *this* exception, which my program expects,
// let any
> On Oct 21, 2019, at 5:10 AM, David Negrier
> wrote:
>
> Hey list,
>
> TL;DR:
>
> I'm considering writing an RFC (and a patch) to turn some warning into
> exceptions in a number of PHP functions.
> I would first like to gather some feedback here.
JMTCW, which is an opinion admittedly
> I agree with the distinction described by Nikita.
> There are definitely cases where a special return value is still the
> best option.
I personally like exceptions in all cases, as they allow for fine-grained
error handling, for example:
```
try {
mkdir('somedir');
} catch
I agree with the distinction described by Nikita.
There are definitely cases where a special return value is still the
best option.
In addition I would say in some cases it can be useful to have both
versions available: One that returns FALSE or NULL, another that
throws an exception.
This is for
On 21/10/2019 17:02, Rowan Tommins wrote:
- They immediately jump control out of the current frame of execution.
Unless you put a separate "try-catch" around every line, there is no
"acknowledge and run next line".
I've been toying with the idea of:
$x = tryval fopen('missing.txt', 'r'),
Hi David,
Firstly, I agree with Nikita's general rule of which Warnings should be
promoted and which need deeper thought.
I would like to challenge one assertion in your e-mail, which is related to
that thought process:
On Mon, 21 Oct 2019 at 14:52, David Negrier
wrote:
> We would be happy
On Mon, Oct 21, 2019 at 3:52 PM David Negrier <
d.negr...@thecodingmachine.com> wrote:
> Hey list,
>
> TL;DR:
>
> I'm considering writing an RFC (and a patch) to turn some warning into
> exceptions in a number of PHP functions.
> I would first like to gather some feedback here.
>
> The long
On 20.10.2019 at 17:00, Colin O'Dell wrote:
> Is there any particular reason why the substr() function doesn't accept a
> null $length like mb_substr() does? It seems the behavior to read through
> the end of the string can only be controlled by the presence or absence of
> the $length
On Mon, Oct 21, 2019 at 5:03 PM Colin O'Dell wrote:
> Hello Internals,
>
> Is there any particular reason why the substr() function doesn't accept a
> null $length like mb_substr() does? It seems the behavior to read through
> the end of the string can only be controlled by the presence or
> I'm considering writing an RFC (and a patch) to turn some warning into
> exceptions in a number of PHP functions.
> I would first like to gather some feedback here.
I would *LOVE* if these functions could be fixed, and if I had the almighty
merge button at my disposal, I'd press it whenever
On 21-10-19 11:10, David Negrier wrote:
> I'm considering writing an RFC (and a patch) to turn some warning into
> exceptions in a number of PHP functions.
> I would first like to gather some feedback here.
I think this is definitely worth a shot. My suggestion would be to split
the effort in
On Mon, 21 Oct 2019 at 15:13, Mike Schinkel wrote:
> Ok, so let's look at a scenario. Will we be able to do this in the future,
> if we decide to allow multiple expressions to result in a final value?
> $y = switch ($x) {
>case 1 => $arr = get_array(), array_pop($arr),
>case -1 => $arr
Hello Internals,
Is there any particular reason why the substr() function doesn't accept a
null $length like mb_substr() does? It seems the behavior to read through
the end of the string can only be controlled by the presence or absence of
the $length parameter: https://3v4l.org/YpuO1
I
> On Oct 20, 2019, at 7:59 AM, Rowan Tommins wrote:
> On 19/10/2019 17:40, Kosit Supanyo wrote:
>> Like function declaration and function expression in JavaScript, if
>> `switch` appears as first token at statement level it will be recognized as
>> statement but if `switch` is in expression
Hi Rowan
I'm not sure is the right syntax for type guards, but it's possible
> we'd want a different syntax for new switch/match functionality anyway.
I've decided to change the syntax to `(: foo)`. It may look weird at frist
but it is able explain why I think this syntax is more appropriate.
On Sun, 20 Oct 2019 at 22:35, Mike Schinkel wrote:
> What restriction are you referring to? The forced `default` or the
> semi-colon being required?
>
>
Neither; I was referring to not being able to put a switch expression as a
statement on its own, which Kosit has explained is a limitation of
Hi Mike
> Ok, so let's look at a scenario. Will we be able to do this in the future,
> if we decide to allow multiple expressions to result in a final value?
> $y = switch ($x) {
> case 1 => $arr = get_array(), array_pop($arr),
> case -1 => $arr = get_array(), array_unshift($arr),
>
Hi Mike
In a brace-enclosed block statements are separated by semi-colons, not
> commas.
Yes because they are statements, that's the point which I've stated many
times. And if your argument is that there's no place in PHP that uses
commas within curly braces, you're wrong. PHP already has one.
> On Oct 20, 2019, at 7:28 AM, Rowan Tommins wrote:
> On 20/10/2019 01:39, Mike Schinkel wrote:
>> Not yet having experience working on PHP's parser I do not know how it is
>> configured nor what about the design of PHP requires keywords unable to be
>> used as constants, class names, function
> On Oct 20, 2019, at 7:08 PM, Kosit Supanyo wrote:
>
> Yes because they are statements, that's the point which I've stated many
> times.
And I am suggesting that a block-enclose expression should not be limited to
expressions only, but instead be able to use statements in the future. Using
Hey list,
TL;DR:
I'm considering writing an RFC (and a patch) to turn some warning into
exceptions in a number of PHP functions.
I would first like to gather some feedback here.
The long version:
It is the first time I'm posting on internals.
Some of you may already know me. I'm one of the
Hi Kosit,
On Sun, 20 Oct 2019 at 16:20, Kosit Supanyo wrote:
> You can recognize the difference of those by looking for `=>` right? But
> the parser generator (bison) cannot do that in LR mode (it maybe can in GLR
> mode but I'm sure that would be unacceptable due to performance losses/more
>
Hi Kosit,
Thank you for your reply.
> On Oct 20, 2019, at 3:54 AM, Kosit Supanyo wrote:
>
> Hi Mike
>
> Is there a strong reason to change to using fat arrows and colons?
>
> The reason is statement/expression semantic.
Okay, so you chose commas and fat arrows because of perceived
Hi Rowan
Thank you for your reply.
Was this restriction added to make the implementation easier, or because
> you thought it was a useful feature?
>
This is not a restriction but a result of implementation workarounds. Let's
see:
switch ($x) {
case 1:
echo "ONE\n";
break;
35 matches
Mail list logo
