Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
"Kalle Sommer Nielsen" wrote in message news:CAJW__o3QJOe6G3ybmBcoCU=fcadjzacgbktijrbm3rs8q0h...@mail.gmail.com... 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, I totally agree that compiler writing is hard, which is why I believe that only those things which are hard to do in userland code should be added to the language. 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. For me the rule is simple - if something can already be done quite easily in userland code then it should not be forced into the language just because a small number of developers wnat to save themselves a few keystrokes. Making the language more complicated than it need be leads to a maintenance burden both for the core developers and the application developers who now have to deal with a growing array of indeciferable shortcuts. 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. This type of checking can quite easily be done in userland code, so I see no reason why it should be built into the language. What percentage of userland developers would actually use such a feature? I wouldn't as I never pass around arrays of single types. I regularly use the $_POST array and a database record array which are both of mixed types. 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 I disagree. The language has to be changed to recognise that type of argument, then it has to iterate through the array checking that every member is of the designated type. In other words the langage now has to do what you are doing with a few lines of userland code. 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 If it's put into the language then it affects 100% of the users, but what percentage of the user base would actually take advantage of this feature? If it's only 1% then for the other 99% it's a complete waste of time. 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. It has complications in the language that are not used. Have you ever heard o the 80-20 rule? This is where 80% of the usage is simple and 20% is complicated, but that complicated 20% takes up 80% of the programming effort. I was around in the 1980s during the switch to RISC (Reduced Instruction Set Computers) where it was found that by removing the complicated instructions which could be execute
Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
Am 02.11.2017 um 10:55 schrieb Tony Marston: "Kalle Sommer Nielsen" wrote in message 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 If it's put into the language then it affects 100% of the users, but what percentage of the user base would actually take advantage of this feature? If it's only 1% then for the other 99% it's a complete waste of time how does any feature you don't use affect you? i don't care about pdo and many other core extensions nor about namespaces, traits and so on - but they don't affect me at all -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes
On 2 November 2017 04:24:17 GMT+00:00, Stanislav Malyshev wrote: >Hi! > >> From the body of the RFC: >> >> "To enable for the closing marker to be indented, ... The indentation >> of the closing marker dictates the amount of whitespace to strip from >> each line within the heredoc/nowdoc" > >Yes, that's what the RFC says. But the voting question only mentions >indenting the marker. I'd prefer voting options were clear and I didn't >have to second-guess the intent. It could be "Allow indenting the >marker >and stripping the whitespace?" and all would be clear. I would add that this is particularly important on an RFC with two or more votes. On most RFCs, the voting question is implied to be "accept the change/feature as described above", but as soon as you have two votes, it's important to be clear which parts of the proposal are covered by each vote. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes (voting restarted)
Hi all, > I would add that this is particularly important on an RFC with two or more > votes. On most RFCs, the voting question is implied to be "accept the > change/feature as described above", but as soon as you have two votes, it's > important to be clear which parts of the proposal are covered by each vote. As per feedback here, I have updated the first voting question for additional clarification. This has restarted the vote for the first question only. The second vote will continue as normal, and both will still end on the same date (November 15th). Sorry for the inconvenience. -Tom
Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes (voting restarted)
On 2 November 2017 at 11:35, Thomas Punt wrote: > Hi all, > > > > I would add that this is particularly important on an RFC with two or > more votes. On most RFCs, the voting question is implied to be "accept the > change/feature as described above", but as soon as you have two votes, it's > important to be clear which parts of the proposal are covered by each vote. > > > As per feedback here, I have updated the first voting question for > additional clarification. This has restarted the vote for the first > question only. The second vote will continue as normal, and both will still > end on the same date (November 15th). > > Link to RFC: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes > > Sorry for the inconvenience. > > -Tom >
Re: [PHP-DEV] RFC - Array Of for PHP 7
On 01/11/2017 01:36, Andrea Faulds wrote:
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[]).
That would be a shame, TypeName[] is a defacto standard already for PHP
docs (not to mention a absolute standard for many programming languages)
and if it can be made to work it would be one less piece of syntax.
IMHO ?(int[]) would be the way to go staying with the current trend, or
alternatively bite the bullet and specific both like we do in docblocs:
function fn(null | int[] $x) { ... }
Generics gives the less ambiguous option:
function fn(?array $x) { ... }
This would become a lot less of an issue if we had function overloading
in future *crosses fingers*.
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.
Which brings up perhaps a longer term point, does the language need an
inbuilt alternative to "array" that implements ArrayAccess and provides
for an "Operator array" that will allow it to be cast to an native array
just as __tostring does for objects that implement it.
The benefit would be that type checking could be performed on
initialization and assignment, and with "operator array" it would be
transparent.
The downside I see? Well, being a generic object it would not exhibit
traditional PHP copy-on-write behaviour, unless that was somehow baked
into the language as part of the class definition (in a similar manner
to "abstract" or "implements CopyOnWrite").
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?
Would an "operator array" not solve this in the same manner that
__tostring does?
I think once we have operator overloading (and supported by native
types) then we should be able to do the following:
function fn(MyCollection $y) { ... }
generic class MyCollection {
public function __construct(array $in) {
foreach ($in as $x) {
if (!($x typeof T1)) {
throw new InvalidArgumentException('...');
}
}
}
}
fn(['hello', 'world']);
And the engine should be smart enough to create a new instance of
MyCollection with the defined constructor. I say overloading would
be necessary as several different constructors may be required.
Equally:
generic class SomeArray {
...
public function __operator_array(): array {
return $this->privateInternalArray;
}
...
}
function fn(array $x) { ... }
fn(new SomeArray(1, 2, 3));
Admittedly I do not know the PHP core with any degre of intimacy, but
from a language perspective I can't think of a better way than generics,
casting operators, and overloaded function constructors...
... and yes, that did include almost every major language wishlist item
in a single go. Chalk it up to me romancing my long lost love of C++.
Thanks.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array Of for PHP 7
On 11/01/2017 11:31 PM, Michael Morris wrote:
> Drupal 8 accomplishes this through assert() and a helper class.
>
> function foo ( array $a ) {
> assert( Inspector::assertAllStrings( $a ));
> }
>
> This could be improved by having an collectionof operator similar to the
> instanceof operator.
>
> function ( array $a ) {
> assert( $a collectionof string );
> }
>
> I say "collectionof" because while arrays are the most common traversable
> objects, they aren't the only ones. The above approach, combined with the
> existing assert structure, can provide the dev time checking of the code
> while in under development, and it can be turned off in production. Or it
> can be used outside of assert to be checked at all times.
>
> Since this invokes a new keyword I think that would mean this solution
> would be PHP 8.
>
> Brackets might be used with instance of to notify it to traverse down one
> level maybe??
>
> function ( array $a ) {
> assert( $a instanceof [string] );
> }
>
> This avoids any BC issues, but it looks odd. Not as odd as \ for a
> namespace operation :P But odd.
While I normally strongly agree with supporting all traversables, not
just arrays, in this case I don't think it works. The whole point of
using a traversable is that you don't have all of the values up front.
If you did... you'd just have an array. So checking "all values" of a
traversable in one point in time is a destructive operation as it runs
out the iterator, which if it's an infinite iterator could, erm, be bad.
Rather, arrays can/should be checked at once (as above), whereas a
traversable should be able to declare that it only returns a given type,
and if it ever tries to return a different type then the traversable
itself type-errors.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes (voting restarted)
Hi! > As per feedback here, I have updated the first voting question for > additional clarification. This has restarted the vote for the first > question only. The second vote will continue as normal, and both will > still end on the same date (November 15th). Thank you! -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array Of for PHP 7
On Thu, Nov 2, 2017 at 3:21 PM, Larry Garfield wrote: > > While I normally strongly agree with supporting all traversables, not > just arrays, in this case I don't think it works. Hmm.. You're right. Traversables would be best served by having another method to indicate their return type as part of the interface. Adding this to the existing traversable interface would be BC breaking. A new interface would be best and having another interface isn't without precedent - countable already exists. This new interface would the PHP engine on what to do. So, what about this syntax $a instanceof string[] If the engine sees this and it's an array, all the values are checked to see if it's a string. Else if $a references a generator, the return type definition of the generator will be checked, and a failure will occur if the generator doesn't declare its return type. Else if $a references an object and that object implements the SingleReturnType* interface then the method of that interface, getReturnType() is queried and it's return is checked to see if it matches. In the above case 'string' would need to be returned. I leave it to people smarter than me to find the holes in the above, but this moron thinks it might work. * Someone smarter than me can come up with a better name too :P
Re: [PHP-DEV] RFC - Array Of for PHP 7
Hi,
Mark Randall wrote:
On 01/11/2017 01:36, Andrea Faulds wrote:
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[]).
That would be a shame, TypeName[] is a defacto standard already for PHP
docs (not to mention a absolute standard for many programming languages)
and if it can be made to work it would be one less piece of syntax.
IMHO ?(int[]) would be the way to go staying with the current trend,
Yes, it is a bit unfortunate to deviate from the docs. But array<> is
also a familiar syntax, yet it's unambiguous and wouldn't require the
new complication of parentheses. For that reason I don't find [] a
compelling option. Syntax æsthetics are nice but in the end it's
readability that matters.
or
alternatively bite the bullet and specific both like we do in docblocs:
function fn(null | int[] $x) { ... }
Generics gives the less ambiguous option:
function fn(?array $x) { ... }
This makes things even more complicated.
This would become a lot less of an issue if we had function overloading
in future *crosses fingers*.
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.
Which brings up perhaps a longer term point, does the language need an
inbuilt alternative to "array" that implements ArrayAccess and provides
for an "Operator array" that will allow it to be cast to an native array
just as __tostring does for objects that implement it.
The benefit would be that type checking could be performed on
initialization and assignment, and with "operator array" it would be
transparent.
The downside I see? Well, being a generic object it would not exhibit
traditional PHP copy-on-write behaviour, unless that was somehow baked
into the language as part of the class definition (in a similar manner
to "abstract" or "implements CopyOnWrite").
Why create an almost-array that works almost-everywhere when you can
improve the actual array that works actually everywhere?
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?
Would an "operator array" not solve this in the same manner that
__tostring does?
Your proposed objects would not be usable everywhere an array is,
because they're not arrays, and by converting to an array you lose the
type info, so we still have to iterate over the whole thing to type
check. This would be significantly less useful than an actually typed
array. I can see some benefit to it, but I'm not sure it's worth the effort.
I think once we have operator overloading (and supported by native
types) then we should be able to do the following:
function fn(MyCollection $y) { ... }
generic class MyCollection {
public function __construct(array $in) {
foreach ($in as $x) {
if (!($x typeof T1)) {
throw new InvalidArgumentException('...');
}
}
}
}
fn(['hello', 'world']);
And the engine should be smart enough to create a new instance of
MyCollection with the defined constructor. I say overloading would
be necessary as several different constructors may be required.
Equally:
generic class SomeArray {
...
public function __operator_array(): array {
return $this->privateInternalArray;
}
...
}
function fn(array $x) { ... }
fn(new SomeArray(1, 2, 3));
A problem here is that we'd need to implement generics! That's quite the
complex task. I do like the idea of generics, but I don't really expect
them to get implemented (let alone accepted) any time soon. Maybe if I
suddenly decide to take all my yearly paid holiday at once and am
unusually determined. But there are much nicer things to go on holiday for…
Admittedly I do not know the PHP core with any degre of intimacy, but
from a language perspective I can't think of a better way than generics,
casting operators, and overloaded function constructors...
... and yes, that did include almost every major language wishlist item
in a single go. Chalk it up to me romancing my long lost love of C++.
We all have our wishlist features. :)
I think I share some of yours.
Thanks for your reply.
Thanks.
--
Mark Randall
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array Of for PHP 7
On 03/11/2017 02:27, Andrea Faulds wrote: Your proposed objects would not be usable everywhere an array is, because they're not arrays, and by converting to an array you lose the type info, so we still have to iterate over the whole thing to type check. This would be significantly less useful than an actually typed array. I can see some benefit to it, but I'm not sure it's worth the effort. Thanks for the reply. So if I am following right, would your goal in the short-to-mid term at least be to attach type information inside the HashTable, or as part of the zval value? I may be pulling this out our my arse of course, but does the nature of an array not mean that the individual values inside can be used as references and potentially break the type restrictions and require all-item checking again? $t1 = array([ 'hello', 'goodbye']); $val = &$t1[1]; $val = 1; -> [ 'hello', 1] I did take a look in zend_types.h half expecting to see a pointer to an optional structure defining an indirect function call + argument to be called whenever the zval_value was about to be changed, but if it's in there, I missed it. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
