Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101026
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2C3A2443-8680-4FA7-BD25-872472506D03@gmail.com>
References: <CALTzvrKFLnCW4+D-FU4cp2rmOScF77vZFz4f1cuVP3VyMzkkeg@mail.gmail.com>
 <CA+kxMuQ92GjSnNPx-atA6N-ot_DJnjjdF72DDbQFdRZL2cit4w@mail.gmail.com>
 <CAFMT4Nros2d82OLexzwQuHjBEggMV04n8K8sqWzc0rxU--Yu5g@mail.gmail.com> <2C3A2443-8680-4FA7-BD25-872472506D03@gmail.com>
Date: Thu, 2 Nov 2017 00:31:59 -0400
Message-ID: <CAEUnE0fbXnOXXz=k32rRYx5mK85TS_ktrVh5W_spgdeNPSzpnA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c0a8c4a1cb127055cf8780e"
Subject: Re: [PHP-DEV] RFC - Array Of for PHP 7
From: tendoaki@gmail.com (Michael Morris)

--94eb2c0a8c4a1cb127055cf8780e
Content-Type: text/plain; charset="UTF-8"

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.


On Wed, Nov 1, 2017 at 10:40 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 31 October 2017 17:37:17 GMT+00:00, Levi Morrison <levim@php.net>
> wrote:
> >  - 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.
>
> Do you have a mechanism in mind for "optimising this away"? I think
> releasing the feature without any optimisation will just lead to painful
> slowdowns when people use it without realising the implications.
>
> As I said in my previous message, it seems to be a fundamental issue with
> PHP's current type declarations that they are a) runtime, and b) asserted
> at arbitrary points, not at assignment. So even if you optimise the check
> slightly, it's still a separate check every time you enter a new function,
> which puts a limit on optimisation.
>
> The only way I've thought of to improve things is to cache the result of
> previous type checks, but this comes with all the normal challenges of
> caching. For instance, all assignments into the array would need to
> invalidate these cached checks, or check the new value against each.
> References would be particularly tricky, as they were with the property
> type hint proposal.
>
> If we selectively invalidated cached checks, we'd be running specific type
> checks at every variable assignment, but not letting the user actually
> assert on those checks. At which point, should we approach from the other
> direction, and let the user declare variable types, rather than assert
> value types?
>
> This is kind of implied if we implement generics, too, since explicitly
> constructing an instance of list<int> is asking the runtime to check future
> assignments to members of that list. In effect, could declaring "int $foo =
> 42;" be considered equivalent to "$foo = new checkedScalar<int>(42);"?
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--94eb2c0a8c4a1cb127055cf8780e--