Re: [PHP-DEV] Progress or just 'a mess'?

[Stanislav Malyshev]

Hi!

> picking up on the base problem? Just what character set is PHP7 designed
> to work with.

What do you mean by "work with"?

> For PHP8 is it not time to lay out a similar set of rules as provided by
> SQL and identify just what 'case-insensitive' means and where it does apply?

I'm not sure which problem you are trying to solve here. Could you
explain what you'd be using these rules for?
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Tony Marston]

wrote in message news:098adca8-6897-929d-90e4-cc464f0e2...@rhsoft.net...




Am 19.09.2017 um 11:24 schrieb Tony Marston:
If the single character  "ß" represents two "s" characters joined 
together, then the uppercase equivalent should also be a single character 
which looks like two "S" characters joined together. If it is not 
possible to write code which deals with these exceptions, then one 
alternative would be to remove these exceptions


remove from where?
from the reality?


If the lowercase character "ß" causes so many problems because it has no 
proper equivalent in uppercase then it should be removed from the list of 
valid characters. Either that or provide a single uppercase character - 
which is what that wikipedia article you quoted says actually happened this 
year.


have fun, it becomes even more complexer and currently it's in discussion 
where to place the uppercase on a keyboard

https://en.wikipedia.org/wiki/%C3%9F#Capital_form

> If the single character "ß" represents two "s"

no, until short ago there where just no uppercase one and that's only about 
german - you still missed *to prove* "Removing case insensitivity 
completely is not a proper solution as it removes a feature that we humans 
have been used to for decades"


When we search for a word in a dictionary we do not need to specify case as 
that is irrelevant, so "sausage" is the same as "SAUSAGE". There are words 
which can have different meanings depending on the context, such as "this 
cup is made of china" and "I am going to China", but provided that the 
context remains the same then case is irrelevant.


When it comes to software case insensitivity has been the standard since day 
1. When searching for a file in MS Windows you do not have to specify case 
as it is not possible to have different files with the same name but 
different mixtures of case.


When searching for a word or phrase in a text editor it is not necessary to 
specify case, although some editors include an option to make the search 
case sensitive.


since i know nobody right in his mind which writes inconsistent code where 
this is a real world problem and if someone writtes "my_function", 
"MY_function" and "my_Function" in his code and don#t stop that nosnese he 
simply get fired


That may be uncool, but the only problem it causes is in the tiny minds of 
OCD sufferers. By making the language case sensitive and allowing 
"my_function", "MY_function" and "my_Function" to be defined as separate 
functions with separate implementations would be inviting total disaster.


--
Tony Marston


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

Re: [PHP-DEV] Progress or just 'a mess'?

[Lester Caine]

On 20/09/17 08:26, Stanislav Malyshev wrote:
>> picking up on the base problem? Just what character set is PHP7 designed
>> to work with.
> 
> What do you mean by "work with"?

Actually that HAS already been identified in this thread, and it is only
the basic ASCII character set, but this is not actually specified anywhere?

>> For PHP8 is it not time to lay out a similar set of rules as provided by
>> SQL and identify just what 'case-insensitive' means and where it does apply?
> 
> I'm not sure which problem you are trying to solve here. Could you
> explain what you'd be using these rules for?

Having established that the only characters that are case-insensitive in
PHP7 ... the unicode basic latin set ... the discussion SHOULD be on
either expanding that to cover all case folding or simply removing this
rather limited case? Tony Marston is making an impassioned demand to
retain this very limited case, and therefore expand it to cover all
character sets, and as a fellow 'English only' coder, I can accept that
argument. However many of my clients do not use English as a first
language so any data handling has to be unicode based, and case in that
data can be important, so is case-insensitive really as universal as
Tony thinks? Certainly we need data case-insensitivity to handle unicode
properly and not just a few english characters ( should I really add a
capital 'E' to english just to please the spell checker? )

People are using their own languages when writing PHP variables and
function names, and apart from a few edge cases this does seem to be
working for them. As with SQL, the key programming words are in English,
and I don't think anybody would suggest adding aliases for them, so
restricting keywords to 'unicode basic latin set' can be defined, but
does THEN making that case-insensitive add to the problems of making PHP
more user friendly in handling unicode names elsewhere? I am seeing SQL
field names coming in with unicode content, and these are then array
keys in PHP ... the latin characters get lower cased at times and this
DOES cause a problem if the metadata defines upper case and I suspect
that is something that will never be changed now, but the actual rules
applied would be nice to know?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2

[Nikita Popov]

On Wed, Sep 20, 2017 at 6:32 AM, Sara Golemon  wrote:

> I was planning to update the RFC, but wiki.php.net is having issues
> atm and isn't coming back up with basic coaxing, so I'll just start
> discussion informally, and the RFC can be updates later.
>
> Background: I made an RFC some time ago to implement HackLang's Pipe
> Operator https://docs.hhvm.com/hack/operators/pipe-operator which
> provides fluent calling for non-object interfaces.
> I circulated it to mixed reviews, many negative, with the negativity
> feeling like it centered on the use of a magic placeholder token `$$`.
>
> After discussion with Levi and others who suggested a simpler
> approach, I'd like to offer
> https://github.com/php/php-src/compare/master...sgolemon:pipe2 as an
> alternate possibility.
>
> This version removes the $$ token, and instead treats the RHS of the
> expression as a callable obeying the same rules as the callable
> typehint elsewhere in the language.  Specifically:
> * Free functions as strings containing the function name. (e.g. 'funcname')
> * Object methods as array($object, 'methodname')
> * Static methods as array('Classname', 'methodname')
> * Closure expression (e.g.  function($x) { return ...; }  )
> * Object instance with an __invoke() method.
>
> In a given pipe expression, the output of the LHS expression feeds a
> single arg to the callable on the RHS.
> Examples:
>
> $x = "hello"
> |> 'strtoupper'
> |> function($x) { return $x . " world"; };
> // $x === "HELLO world"
>
> Non-Goal: I didn't include support for base function names (e.g.
> `"hello" |> strtoupper`) because of the conflict with constants.
> Using a constant to store your function name is totes legit and
> consistent with language syntax.
>
> Future Scope: Short Lambdas `$x => $x + 1` and Partial Functions
> `someFunc('fixed val1', ..., 'fixed val2')`  would help make this
> functionality more useful and are worth discussing as a sub-thread,
> but are not required to be implemented at the same time.
>

I think this feature makes very little sense if it's not introduced
together with a way of making partial application much more ergonomic than
it is now. I understand the desire to keep things separate, but I don't
think that this proposal can land without partial application syntax being
introduced beforehand or in conjunction with it.

>From a previous R11 discussion, I remember that two strong contenders were
foo(...) for getting a callable with an arbitrary number of unbound
parameters and foo($$) for a single unbound parameter. In the latter case
the proposal has a similar expressive power as the previous pipe operator
proposal. Another option was to make $$ a more general construct for
obtaining single-parameter closures in compact form. Then you would also be
able to write "$$->getFoo()" to get the equivalent of "function($x) {
return $x->getFoo(); }" and similar. A disadvantage is that the precedence
here is less clear and that a short closure syntax might be more clear for
the cases that go beyond partial application.

Regards,
Nikita

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Lester Caine]

On 20/09/17 10:30, Tony Marston wrote:
> When it comes to software case insensitivity has been the standard since
> day 1. When searching for a file in MS Windows you do not have to
> specify case as it is not possible to have different files with the same
> name but different mixtures of case.

When M$ screwed up the filing system by allowing spaces in file names
and also dropping case sensitivity - to make life easier for none
programmers - we had to get use to this 'new way of working'. It STILL
causes problems today so no it was NOT standard from day 1. Although I
can't remember now if DOS 8.3 file names enforced uppercase only but all
other OS's at that time preserved case in file names.
https://en.wikipedia.org/wiki/8.3_filename explains how VFAT added
longer file names to FAT ... using an upper case file name below.

File capabilities on
https://en.wikipedia.org/wiki/Comparison_of_file_systems will
demonstrate just how few file systems are case-insensitive. You will see
that NTFS is ACTUALLY case-sensitive and it is only the WIN32 subsystem
which prevents file names clashes. It's also that system which changes
the case of a name when it's displayed or passed over to other systems :(

That all said ... the rather limited question here is if the current
very restricted case-insensitivity should be removed, or should it be
expanded to properly handle constant names in other character sets? That
then needs a LOT of work in other areas where the limited ascii
case-insensitivity is allowed? Do we NEED case-insensitivity if that is
one thing preventing a switch to use of unicode names in the code?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[li...@rhsoft.net]

Am 20.09.2017 um 11:30 schrieb Tony Marston:

wrote in message news:098adca8-6897-929d-90e4-cc464f0e2...@rhsoft.net...




Am 19.09.2017 um 11:24 schrieb Tony Marston:
If the single character  "ß" represents two "s" characters joined 
together, then the uppercase equivalent should also be a single 
character which looks like two "S" characters joined together. If it 
is not possible to write code which deals with these exceptions, then 
one alternative would be to remove these exceptions


remove from where?
from the reality?


If the lowercase character "ß" causes so many problems because it has no 
proper equivalent in uppercase then it should be removed from the list 
of valid characters. Either that or provide a single uppercase character 
- which is what that wikipedia article you quoted says actually happened 
this year


jesus christ the german language DID NOT have a uppercase ß in the real 
world until recently but had the lowercase ß virtually forever


how do you imagine "removeed from the list of valid characters" in that 
case - frankly that paragraph above shows clearly that you should stop 
to argue about this topic at all


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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[Jay B]

>
> That may be uncool, but the only problem it causes is in the tiny minds of
> OCD sufferers.
>

Once again, you are being derogatory and continue to label others, who do
not share your opinion, with a mental health condition.

As you have been told previously (thread - https://externals.
io/message/99241#99241);

What you seem not to recognise is that any person has the right to
> suggest or campaign for such a change, regardless of their age, experience
> level, pay grade, nerdiness or severity of OCD. To imply otherwise is
> offensive.
>

It's a shame that you're unable to have a discussion, on a public mailing
list, without being rude, offensive and derogatory.
It'd be better if you could stay on topic rather than sharing your thoughts
on the mental health of others.

On Wed, Sep 20, 2017 at 10:30 AM, Tony Marston 
wrote:

> wrote in message news:098adca8-6897-929d-90e4-cc464f0e2...@rhsoft.net...
>
>>
>>
>>
>> Am 19.09.2017 um 11:24 schrieb Tony Marston:
>>
>>> If the single character  "ß" represents two "s" characters joined
>>> together, then the uppercase equivalent should also be a single character
>>> which looks like two "S" characters joined together. If it is not possible
>>> to write code which deals with these exceptions, then one alternative would
>>> be to remove these exceptions
>>>
>>
>> remove from where?
>> from the reality?
>>
>
> If the lowercase character "ß" causes so many problems because it has no
> proper equivalent in uppercase then it should be removed from the list of
> valid characters. Either that or provide a single uppercase character -
> which is what that wikipedia article you quoted says actually happened this
> year.
>
> have fun, it becomes even more complexer and currently it's in discussion
>> where to place the uppercase on a keyboard
>> https://en.wikipedia.org/wiki/%C3%9F#Capital_form
>>
>> > If the single character "ß" represents two "s"
>>
>> no, until short ago there where just no uppercase one and that's only
>> about german - you still missed *to prove* "Removing case insensitivity
>> completely is not a proper solution as it removes a feature that we humans
>> have been used to for decades"
>>
>
> When we search for a word in a dictionary we do not need to specify case
> as that is irrelevant, so "sausage" is the same as "SAUSAGE". There are
> words which can have different meanings depending on the context, such as
> "this cup is made of china" and "I am going to China", but provided that
> the context remains the same then case is irrelevant.
>
> When it comes to software case insensitivity has been the standard since
> day 1. When searching for a file in MS Windows you do not have to specify
> case as it is not possible to have different files with the same name but
> different mixtures of case.
>
> When searching for a word or phrase in a text editor it is not necessary
> to specify case, although some editors include an option to make the search
> case sensitive.
>
> since i know nobody right in his mind which writes inconsistent code where
>> this is a real world problem and if someone writtes "my_function",
>> "MY_function" and "my_Function" in his code and don#t stop that nosnese he
>> simply get fired
>>
>
> That may be uncool, but the only problem it causes is in the tiny minds of
> OCD sufferers. By making the language case sensitive and allowing
> "my_function", "MY_function" and "my_Function" to be defined as separate
> functions with separate implementations would be inviting total disaster.
>
> --
> Tony Marston
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2

[Ilija Tovilo]

Agree.

Even if we already had partial application the previously suggested syntax is 
still more readable IMO. Consider the following example:

```
$array
  |> array_map(function ($element) { ... }, $$);
```

vs

```
$array
  |> apply(flip('array_map'), function ($element) { ... });
```

Not to mention that we'd have to implement `flip` and `apply` ourselves.

Regards


On 20 Sep, 2017, at 12:01 PM, Nikita Popov  wrote:

On Wed, Sep 20, 2017 at 6:32 AM, Sara Golemon  wrote:

I was planning to update the RFC, but wiki.php.net is having issues
atm and isn't coming back up with basic coaxing, so I'll just start
discussion informally, and the RFC can be updates later.

Background: I made an RFC some time ago to implement HackLang's Pipe
Operator https://docs.hhvm.com/hack/operators/pipe-operator which
provides fluent calling for non-object interfaces.
I circulated it to mixed reviews, many negative, with the negativity
feeling like it centered on the use of a magic placeholder token `$$`.

After discussion with Levi and others who suggested a simpler
approach, I'd like to offer
https://github.com/php/php-src/compare/master...sgolemon:pipe2 as an
alternate possibility.

This version removes the $$ token, and instead treats the RHS of the
expression as a callable obeying the same rules as the callable
typehint elsewhere in the language. Specifically:
* Free functions as strings containing the function name. (e.g. 'funcname')
* Object methods as array($object, 'methodname')
* Static methods as array('Classname', 'methodname')
* Closure expression (e.g. function($x) { return ...; } )
* Object instance with an __invoke() method.

In a given pipe expression, the output of the LHS expression feeds a
single arg to the callable on the RHS.
Examples:

$x = "hello"
|> 'strtoupper'
|> function($x) { return $x . " world"; };
// $x === "HELLO world"

Non-Goal: I didn't include support for base function names (e.g.
`"hello" |> strtoupper`) because of the conflict with constants.
Using a constant to store your function name is totes legit and
consistent with language syntax.

Future Scope: Short Lambdas `$x => $x + 1` and Partial Functions
`someFunc('fixed val1', ..., 'fixed val2')` would help make this
functionality more useful and are worth discussing as a sub-thread,
but are not required to be implemented at the same time.


I think this feature makes very little sense if it's not introduced
together with a way of making partial application much more ergonomic than
it is now. I understand the desire to keep things separate, but I don't
think that this proposal can land without partial application syntax being
introduced beforehand or in conjunction with it.

From a previous R11 discussion, I remember that two strong contenders were
foo(...) for getting a callable with an arbitrary number of unbound
parameters and foo($$) for a single unbound parameter. In the latter case
the proposal has a similar expressive power as the previous pipe operator
proposal. Another option was to make $$ a more general construct for
obtaining single-parameter closures in compact form. Then you would also be
able to write "$$->getFoo()" to get the equivalent of "function($x) {
return $x->getFoo(); }" and similar. A disadvantage is that the precedence
here is less clear and that a short closure syntax might be more clear for
the cases that go beyond partial application.

Regards,
Nikita

[PHP-DEV] Confusing type mismatch error messages

[Christoph M. Becker]

Hi everybody!

If a type declaration inadvertently uses `boolean` or `integer` (instead
of `bool` and `int`, respectively), the error message is rather confusing:

  […] must be an instance of boolean, boolean given, […]

This issue has been filed as , and Adam
submitted  to fix that, but
David hinted at the potential BC break, and Joe closed the PR later
stating that such change would require an RFC.

In my opinion, it would be sufficient to change the error message so
that the canonical name of the type would be used, i.e. `bool` and
`int`, respectively, so the message above would read:

  […] must be an instance of boolean, bool given, […]

This change would still be a BC break, but at a far smaller scale than
Adam's PR would have been.

So I am asking for opinions whether this change would be worth the BC
break, and whether a respective RFC could target PHP 7.3, or would have
to wait for PHP 8.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2

[Derick Rethans]

On Wed, 20 Sep 2017, Nikita Popov wrote:

> On Wed, Sep 20, 2017 at 6:32 AM, Sara Golemon  wrote:
> 
> > I was planning to update the RFC, but wiki.php.net is having issues
> > atm and isn't coming back up with basic coaxing, so I'll just start
> > discussion informally, and the RFC can be updates later.



> > Non-Goal: I didn't include support for base function names (e.g.
> > `"hello" |> strtoupper`) because of the conflict with constants.
> > Using a constant to store your function name is totes legit and
> > consistent with language syntax.
> >
> > Future Scope: Short Lambdas `$x => $x + 1` and Partial Functions
> > `someFunc('fixed val1', ..., 'fixed val2')`  would help make this
> > functionality more useful and are worth discussing as a sub-thread,
> > but are not required to be implemented at the same time.
> >
> 
> I think this feature makes very little sense if it's not introduced
> together with a way of making partial application much more ergonomic than
> it is now.

What do you mean here by "partial application"?

cheers,
Derick

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

Re: [PHP-DEV] Confusing type mismatch error messages

[Derick Rethans]

On Wed, 20 Sep 2017, Christoph M. Becker wrote:

> Hi everybody!
> 
> If a type declaration inadvertently uses `boolean` or `integer` (instead
> of `bool` and `int`, respectively), the error message is rather confusing:
> 
>   […] must be an instance of boolean, boolean given, […]
> 
> This issue has been filed as , and Adam
> submitted  to fix that, but
> David hinted at the potential BC break, and Joe closed the PR later
> stating that such change would require an RFC.
> 
> In my opinion, it would be sufficient to change the error message so
> that the canonical name of the type would be used, i.e. `bool` and
> `int`, respectively, so the message above would read:
> 
>   […] must be an instance of boolean, bool given, […]

Or why not:

[…] must be an instance of class boolean, boolean given, […]

but I guess we then need to also use "trait" or "interface" as words 
there too.

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

[PHP-DEV] [RFC] Consistent null behaviour

[ilija . tovilo]

Hi everybody!

To my surprise, I noticed today that an array access on a `null` value returns 
`null` without any warning whatsoever.
Accessing the property of a `null` value gives you a notice, while calling a 
function on that `null` value gives you a fatal error.

https://3v4l.org/ZSZHN

This is pretty inconsistent. IMO all of these should be fatal errors, although 
I realize that might be a bit drastic for PHP 8.
We should at least give the user a notice when using array access on a `null` 
value.

Any thoughts?

Regards,
Ilija

Re: [PHP-DEV] Confusing type mismatch error messages

[Christoph M. Becker]

On 20.09.2017 at 18:54, Derick Rethans wrote:

> On Wed, 20 Sep 2017, Christoph M. Becker wrote:
> 
>> This issue has been filed as , and Adam
>> submitted  to fix that, but
>> David hinted at the potential BC break, and Joe closed the PR later
>> stating that such change would require an RFC.
>>
>> In my opinion, it would be sufficient to change the error message so
>> that the canonical name of the type would be used, i.e. `bool` and
>> `int`, respectively, so the message above would read:
>>
>>   […] must be an instance of boolean, bool given, […]
> 
> Or why not:
> 
> […] must be an instance of class boolean, boolean given, […]
> 
> but I guess we then need to also use "trait" or "interface" as words 
> there too.

That has been suggested by Adam, but 62 tests had to be modified,
pointing out the magnitude of this change.  And actually, I still would
be surprised to see such an error message.  It should not be possible to
have a class/interface with the same name as a scalar type – and
actually it is not.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Confusing type mismatch error messages

[ilija . tovilo]

> And actually, I still would be surprised to see such an error message.

This happens when you annotate your function incorrectly:
https://3v4l.org/CoUss


On 20 Sep 2017, 19:08 +0200, Christoph M. Becker , wrote:
> On 20.09.2017 at 18:54, Derick Rethans wrote:
>
> > On Wed, 20 Sep 2017, Christoph M. Becker wrote:
> >
> > > This issue has been filed as , and Adam
> > > submitted  to fix that, but
> > > David hinted at the potential BC break, and Joe closed the PR later
> > > stating that such change would require an RFC.
> > >
> > > In my opinion, it would be sufficient to change the error message so
> > > that the canonical name of the type would be used, i.e. `bool` and
> > > `int`, respectively, so the message above would read:
> > >
> > > […] must be an instance of boolean, bool given, […]
> >
> > Or why not:
> >
> > […] must be an instance of class boolean, boolean given, […]
> >
> > but I guess we then need to also use "trait" or "interface" as words
> > there too.
>
> That has been suggested by Adam, but 62 tests had to be modified,
> pointing out the magnitude of this change. And actually, I still would
> be surprised to see such an error message. It should not be possible to
> have a class/interface with the same name as a scalar type – and
> actually it is not.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2

[Christoph M. Becker]

On 20.09.2017 at 18:52, Derick Rethans wrote:

> On Wed, 20 Sep 2017, Nikita Popov wrote:
> 
>> I think this feature makes very little sense if it's not introduced
>> together with a way of making partial application much more ergonomic than
>> it is now.
> 
> What do you mean here by "partial application"?

Partial application is a common concept in functional/applicative
programming languages, which facilitates to get a closure over another
function where some of the parameters are already applied, e.g.
something like (pseudocode):

  incr = partial(plus, 1);
  print incr(2); // 3
  print incr(100); // 101

-- 
Christoph M. Becker


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

Re: [PHP-DEV] [RFC] Consistent null behaviour

[li...@rhsoft.net]

Am 20.09.2017 um 19:06 schrieb ilija.tov...@me.com:

Hi everybody!

To my surprise, I noticed today that an array access on a `null` value returns 
`null` without any warning whatsoever.
Accessing the property of a `null` value gives you a notice, while calling a 
function on that `null` value gives you a fatal error.

https://3v4l.org/ZSZHN

This is pretty inconsistent. IMO all of these should be fatal errors, although 
I realize that might be a bit drastic for PHP 8.
We should at least give the user a notice when using array access on a `null` 
value.

Any thoughts?
wouldn't that break code like below which is IMHO the best usecase of 
the PHP 5.6 feature that you can directly access a array field of a 
function result and the type-casting encsues that the return-type is 
always int


function GetSKatMaxSort(int $archive=0): int
{
 return (int)mysqli_fetch_row($this->db->query("select SQL_NO_CACHE 
max(ssort) from {$this->db->table} where sarchive=$archive", 1))[0];

}

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

Re: [PHP-DEV] [RFC] Consistent null behaviour

[ilija . tovilo]

I realized after sending the initial E-Mail that there might be more breaking 
changes than I thought, like the one you suggested.

The same thing actually happens for bools, ints and floats:
https://3v4l.org/jvVbO

I wouldn’t depend on this behaviour since you’d get errors depending on what is 
returned, like an empty array, a string, an object or resource.

Regards


On 20 Sep 2017, 19:18 +0200, li...@rhsoft.net , wrote:
>
>
> Am 20.09.2017 um 19:06 schrieb ilija.tov...@me.com:
> > Hi everybody!
> >
> > To my surprise, I noticed today that an array access on a `null` value 
> > returns `null` without any warning whatsoever.
> > Accessing the property of a `null` value gives you a notice, while calling 
> > a function on that `null` value gives you a fatal error.
> >
> > https://3v4l.org/ZSZHN
> >
> > This is pretty inconsistent. IMO all of these should be fatal errors, 
> > although I realize that might be a bit drastic for PHP 8.
> > We should at least give the user a notice when using array access on a 
> > `null` value.
> >
> > Any thoughts?
> wouldn't that break code like below which is IMHO the best usecase of
> the PHP 5.6 feature that you can directly access a array field of a
> function result and the type-casting encsues that the return-type is
> always int
>
> function GetSKatMaxSort(int $archive=0): int
> {
> return (int)mysqli_fetch_row($this->db->query("select SQL_NO_CACHE
> max(ssort) from {$this->db->table} where sarchive=$archive", 1))[0];
> }
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC] Consistent null behaviour

[li...@rhsoft.net]

Am 20.09.2017 um 19:23 schrieb ilija.tov...@me.com:
I realized after sending the initial E-Mail that there might be more 
breaking changes than I thought, like the one you suggested.


The same thing actually happens for bools, ints and floats:
https://3v4l.org/jvVbO

I wouldn’t depend on this behaviour since you’d get errors depending on 
what is returned, like an empty array, a string, an object or resource.


i would depend on that behavior because in reality you can get back two 
different things:


* a numeric array with exactly index 0
* NULL

how do you imagine mysqli_fetch_row() return empty array, string or even 
object/resource? when nothing is found it's a non-empty array and 
otherwise NULL


before PHP 5.6 (or PHP 5.5 not sure) these where useless multiple lines 
because you needed to store the result of mysqli_fetch_row() in some var 
to access key 0



On 20 Sep 2017, 19:18 +0200, li...@rhsoft.net , wrote:



Am 20.09.2017 um 19:06 schrieb ilija.tov...@me.com:

Hi everybody!

To my surprise, I noticed today that an array access on a `null` 
value returns `null` without any warning whatsoever.
Accessing the property of a `null` value gives you a notice, while 
calling a function on that `null` value gives you a fatal error.


https://3v4l.org/ZSZHN

This is pretty inconsistent. IMO all of these should be fatal errors, 
although I realize that might be a bit drastic for PHP 8.
We should at least give the user a notice when using array access on 
a `null` value.


Any thoughts?

wouldn't that break code like below which is IMHO the best usecase of
the PHP 5.6 feature that you can directly access a array field of a
function result and the type-casting encsues that the return-type is
always int

function GetSKatMaxSort(int $archive=0): int
{
return (int)mysqli_fetch_row($this->db->query("select SQL_NO_CACHE
max(ssort) from {$this->db->table} where sarchive=$archive", 1))[0];
}


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

Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2

[Sara Golemon]

On Wed, Sep 20, 2017 at 12:52 PM, Derick Rethans  wrote:
> On Wed, 20 Sep 2017, Nikita Popov wrote:
>> > Future Scope: Short Lambdas `$x => $x + 1` and Partial Functions
>> > `someFunc('fixed val1', ..., 'fixed val2')`  would help make this
>> > functionality more useful and are worth discussing as a sub-thread,
>> > but are not required to be implemented at the same time.
>> >
>>
>> I think this feature makes very little sense if it's not introduced
>> together with a way of making partial application much more ergonomic than
>> it is now.
>>
I generally agree with this statement, and it's why the original
pipe-op (as with hacklang's version) included (a form of) pfa
implicitly.  If that means we should nail down the specifics of PFA
and/or Short-Lambdas before even bothering to move into full draft of
PipeOp, then that's fine.

Levi made the very solid argument that they can be independently
considered even if they compliment each other well, and given the
triviality of the pipe half of that equation, I put it together first
so that we have something to look at.

On the topic of pipe2 specifically:
The positive side of this diff is that it has zero impact on the
backend compiler or opcache since it doesn't produce any new AST
elements.  On the minus side, the AST it produces opaques the original
format.  In practice, this hack is only visible if you're using your
or my ast extensions, or if you use a failing assert.  This is what I
like the least about the approach I included in my link.  It's not the
first place we've hidden original intent behind AST transformations,
but it's certainly the most visually jarring when serialized.

> What do you mean here by "partial application"?
>
$trimX = trim($$, $x);

In this example, trim isn't invoked immediately, instead, $trimX
becomes a callable (closure) which takes a single argument and invokes
trim() with that argument and the captured $x variable.  We've
"partially applied" some arguments to the trim() function, but we
haven't finished forming a function call yet.

Essentially, the above turns into this:
$trimX = function($arg) use ($x) { return trim($arg, $x); };

The '$$' token used by HackLang's PipeOp works well enough because we
know that RHS is only ever going to receive one argument (the result
of LHS).  A more generic approach to PFA would probably involve
allowing for multiple positional arguments, perhaps like:

$myInArray = in_array($2, $1); // Reverse the arg order, effectively

PFA and ShortLambdas have the same scope capture issues however, which
make them thornier issues to tackle.

-Sara

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

[PHP-DEV] Re: [RFC] Consistent null behaviour

[Christoph M. Becker]

On 20.09.2017 at 19:06, ilija.tov...@me.com wrote:

> To my surprise, I noticed today that an array access on a `null` value 
> returns `null` without any warning whatsoever.
> Accessing the property of a `null` value gives you a notice, while calling a 
> function on that `null` value gives you a fatal error.
> 
> https://3v4l.org/ZSZHN
> 
> This is pretty inconsistent. IMO all of these should be fatal errors, 
> although I realize that might be a bit drastic for PHP 8.
> We should at least give the user a notice when using array access on a `null` 
> value.

There is already a respective RFC[1] which has been accepted for PHP
7.2, but there are issues[2].

[1] 
[2] 

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Progress or just 'a mess'?

[Stanislav Malyshev]

Hi!

> Having established that the only characters that are case-insensitive in
> PHP7 ... the unicode basic latin set ... the discussion SHOULD be on
> either expanding that to cover all case folding or simply removing this
> rather limited case? 

Why? Does anybody seriously need Russian case folding in PHP constants?
I mean, sure, nice demo, but does anybody *need* it? I don't see much
code on github - in any language - that uses Russian identifiers, for
example.

> argument. However many of my clients do not use English as a first
> language so any data handling has to be unicode based, and case in that

You seem to be mixing data and code here. So what you are talking about
- data or code?
-- 
Stas Malyshev
smalys...@gmail.com

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