Re: [PHP-DEV] RFC - Array Of for PHP 7

[Andrea Faulds]

Hi Levi,

Levi Morrison wrote:

My thoughts on the RFC:

  - The syntax `typename[]` is a poor. Consider how nullability might
bind `?int[]`. Is that `(?int)[]` or `?(int[])` ? Here are some
variants that do not have this issue:
[?int] and ?[int]
array and ?array


Thank you for bringing this up. The introduction of nullables means that 
the type[] syntax is problematic and should probably be avoided now. As 
you say, there is an issue of ambiguity as to whether it would be 
interpreted as (?int)[] or ?(int[]). Unfortunately, both of these are 
reasonable interpretations and might be desired. So if we use that 
syntax, we'd have to add brackets. It would be simpler and prevent any 
misunderstandings if we use a syntax that is unambiguous in the first place.


Personally I might like generics-esque angular brackets, but a problem 
there is that << and >> are operators with their own tokens, so 
supporting nested arrays (array) would require some sort 
of lexer hack.



  - Our current infrastructure requires us to check every element of
the array for conformance. While undesirable I believe this can be
optimized away in the future if we care enough, and therefore not a
show-stopper.



Something I've thought about but not gotten round to implementing is a 
typed array value. That is, you could write `$x = array(1, 2, 3);` 
and `$x` would contain a typed array that would enforce the types of 
values added to it. This feels like a cleaner solution, but it 
introduces a new issue: does an array type declaration require an 
array value, or will it implicitly cast from vanilla array?


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

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

[PHP-DEV] RFC - Zend VM Pause API

[Haitao Lv]

Hi, internals,

I propose to introduce a new zend vm pause api, and here is the RPF

https://wiki.php.net/rfc/zend-vm-pause-api

Please gave your comment.

Thank you.



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

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[Adam Baratz]

>
> It's possible that daverandom was several hours west of Greenwich at the
> time (e.g. in North America), where it was still late on October 27th. So
> taking the latest of the three published closing dates, and applying the
> most generous time zone, it's possible that all the votes were valid.


https://github.com/DaveRandom

At least according to his GitHub profile, he's in the UK.


> In my opinion, the very fact that it was this close suggests that there is
> not consensus in favour of the change, and therefore it would be reasonable
> to err on the side of caution, and not adopt the change.
>

My take would be that "rules are rules." The RFC was defined as 50%+1.

Thanks,
Adam

Re: [PHP-DEV] RFC - Array Of for PHP 7

[Levi Morrison]

My thoughts on the RFC:

  - The syntax `typename[]` is a poor. Consider how nullability might
bind `?int[]`. Is that `(?int)[]` or `?(int[])` ? Here are some
variants that do not have this issue:
[?int] and ?[int]
array and ?array
  - Our current infrastructure requires us to check every element of
the array for conformance. While undesirable I believe this can be
optimized away in the future if we care enough, and therefore not a
show-stopper.

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

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

[Kalle Sommer Nielsen]

Hi Tony

2017-10-31 11:35 GMT+01:00 Tony Marston :
> This strikes me as being nothing more than a micro-optimisation that does
> nothing but pander to the laziness of certain programmers. Instead of having
> to write a few lines of code to validate something they want the language to
> do it for them. It may come as a surprise to some people, but being a
> programmer actually involves the writing of program code. It is not
> sufficient to express an idea and have the language fill in all the details
> as that forces the language to have to detect and deal with a myriad of
> possibilities.

I do understand where you are coming from, but I don't necessarily
agree on this topic. We can (hopefully) agree that programming
language design is hard, because we need to determine how fine a line
we should have between things thats an integral part of the language,
its standard library or its extensions and how much power the
programmer has in their arsenal to do crazy things.

If we boil things down, then we didn't really need the scalar type
hints, PHP had been working perfectly fine for 20 years without it and
while it does not add anything but a couple of checks at
compile/runtime, its essentially "laziness of certain programmers" it
becomes useful to. Another example is constant visibility modifiers in
PHP 7.1.

I think one of the advocates for features that are within that
category you mention can sometimes be productivity and rid of
boilerplate code. For this case with 'Array Of', I think it makes
perfect sense to add with PHP7's improved type system on that regard,
but thats my personal opinion.

> I would evaluate each proposed change to the language with a simple question
> - does it provide the greatest good to the greatest number? Considering the
> fact that this RFC will only benefit a miniscule minority of developers yet
> make the language more complicated, slower to run, and more difficult to
> maintain as more and more edge cases are identified as "bugs", it offers
> negative benefits to the vast number of programmers who are happy with the
> language as it currently exists. As such it fails that test and should be
> rejected.

Tho you said its a micro optimization, would argue that (see [1]), it
far from makes the code complicated, internally it doesn't add any
complexity and only adds a member to the arg_info, which is an
unsigned char, it wouldn't do anything unless a type is specified
anyway and the slower to run argument above is pretty void, sure it
adds a few CPU instructions but its not something you will feel unless
you are Facebook, in which case you already re-implemented the
language on your own.

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently exists", I
myself don't like PDO, so I just use mysqli instead, great. If its not
something that affects the programmer and the programmers code
continue to run, I fail to see how it negatively impacts the vast
majority. If I asked you how you feel about the exif extension now
supports streams as arguments instead of only file names, would you
care much unless you are actively using the exif extension? Probably
not.


[1] https://gist.github.com/KalleZ/c7ba4f78314c989e27710e4fa14e2f3e



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

[Thomas Hruska]

On 10/31/2017 3:35 AM, Tony Marston wrote:
""Michal Harezlak""  wrote in message 
news:caltzvrkflncw4+d-fu4cp2rmoscf77vzfz4f1cuvp3vymzk...@mail.gmail.com...


Hallo,

I would like to create a RFC for PHP 7, but the same RFC was created and
declined 3 years ago for PHP 5.4. PHP 7 support much better type 
hinging so

I think this RFC should be voted again.

What should I do? Should I create the RPF in common way?

Link to mentioned RFC:
https://wiki.php.net/rfc/arrayof


This strikes me as being nothing more than a micro-optimisation that 
does nothing but pander to the laziness of certain programmers. Instead 
of having to write a few lines of code to validate something they want 
the language to do it for them. It may come as a surprise to some 
people, but being a programmer actually involves the writing of program 
code. It is not sufficient to express an idea and have the language fill 
in all the details as that forces the language to have to detect and 
deal with a myriad of possibilities.


I would evaluate each proposed change to the language with a simple 
question - does it provide the greatest good to the greatest number? 
Considering the fact that this RFC will only benefit a miniscule 
minority of developers yet make the language more complicated, slower to 
run, and more difficult to maintain as more and more edge cases are 
identified as "bugs", it offers negative benefits to the vast number of 
programmers who are happy with the language as it currently exists. As 
such it fails that test and should be rejected.


I agree.

Features that result in significant improvements to algorithmic 
complexity but can't be implemented in userland are the sort of features 
that should be priority for core.  That's another way to look at the 
question that Tony put forth but in more concrete terms.  Internals 
already tends to adhere to that sort of policy anyway even if it isn't 
formally written anywhere.


--
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

[PHP-DEV] Re: RFC - Array Of for PHP 7

[Tony Marston]

""Michal Harezlak""  wrote in message 
news:caltzvrkflncw4+d-fu4cp2rmoscf77vzfz4f1cuvp3vymzk...@mail.gmail.com...


Hallo,

I would like to create a RFC for PHP 7, but the same RFC was created and
declined 3 years ago for PHP 5.4. PHP 7 support much better type hinging so
I think this RFC should be voted again.

What should I do? Should I create the RPF in common way?

Link to mentioned RFC:
https://wiki.php.net/rfc/arrayof


This strikes me as being nothing more than a micro-optimisation that does 
nothing but pander to the laziness of certain programmers. Instead of having 
to write a few lines of code to validate something they want the language to 
do it for them. It may come as a surprise to some people, but being a 
programmer actually involves the writing of program code. It is not 
sufficient to express an idea and have the language fill in all the details 
as that forces the language to have to detect and deal with a myriad of 
possibilities.


I would evaluate each proposed change to the language with a simple 
question - does it provide the greatest good to the greatest number? 
Considering the fact that this RFC will only benefit a miniscule minority of 
developers yet make the language more complicated, slower to run, and more 
difficult to maintain as more and more edge cases are identified as "bugs", 
it offers negative benefits to the vast number of programmers who are happy 
with the language as it currently exists. As such it fails that test and 
should be rejected.


--
Tony Marston


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