Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108189 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60640 invoked from network); 17 Jan 2020 21:38:16 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Jan 2020 21:38:16 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 843F7180540 for ; Fri, 17 Jan 2020 11:45:56 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 17 Jan 2020 11:45:55 -0800 (PST) Received: by mail-lf1-f48.google.com with SMTP id l18so19239283lfc.1 for ; Fri, 17 Jan 2020 11:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xHtP6tbDlZ0HjdqdTc8Fl4+spgSkVcOBc3G+yjV60hM=; b=ccacQ26cO9TViA2C9aXVX5GKdZr99clchr6YxhlMgpa5BbRXG5W9+dAWVDMKx7n4g+ hqUohZ95eQjAfTsq1zN3uVI1m+Vnvpj0CeR6XeejF2n2hhz4bmebxQ27pZ7MFdwJHRF2 kkcH+DvVLi4kxlKpkshF7KKbiSFdArxDteSQkX2+Wlxcqjb0WNDU+906H57TxiHDKjjT OBX40Zh9yLKwUO74mgEpXwyfxtiJ4vN+y/oIMzLK8Yk4pPJTvujGL+8ltNwSiOYH1nwk P+HNFpCEysJ0AZoher0cFIa15+Pvzebd8bHfOJMH9ufd1p9ojK1TrNr8t6tuEIORg4ft Y5lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xHtP6tbDlZ0HjdqdTc8Fl4+spgSkVcOBc3G+yjV60hM=; b=XEy668WV/lmLtd+0kAJ/+w/+3l8EsmHEtf0nxjodTGPIToevT2qg5iAxggh/Wz2QbJ TO1YhZ49ZFnv2FOUEvcbG1NbvndMNJoj3C7Cy1Sm9DnKsDTtv4z3AthYlCUhVWdXg9M0 okFFj7wgqF6g141F9jgHaHuGOtlyrBUQhpmlm3Y9Dkyk39JxEYL5WMKZGM2y7El4a4RG E2ZbAhPorrK3nW1CPK2YnHHJQyN9hONCc+lXa3ZrP+4dyZAgqC5vqVqnW/EuIu/jg7H1 7j+1u+9yt5x8aEm712A3f45Qm2nd/PqsBdJ+hqGMgBNXe4ThVjXre1+s+wy78pZFkVGd bGsA== X-Gm-Message-State: APjAAAWokJC2bJNVm5xBCue1wJ9G9aRatl5yWzmjg/EwhnCr83nxJ+eq gswKHNxPWqarFUDAxW9byPFiSVTbNAeqYcIS0BU= X-Google-Smtp-Source: APXvYqzdX1o9/tqgW3xTYHlP0+/hEWjai/OpgGmBv3t1olBVVSupoQq+CAXSAUnDiZ9yaGl1vh1cYZUB6ZplLgoR8TE= X-Received: by 2002:a05:6512:3a8:: with SMTP id v8mr6310414lfp.187.1579290350528; Fri, 17 Jan 2020 11:45:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 17 Jan 2020 19:45:38 +0000 Message-ID: To: Mike Schinkel , Nikita Popov Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000572c7c059c5b30ac" Subject: Re: [PHP-DEV] Typed array properties V2 From: cdtreeks@gmail.com (Aran Reeks) --000000000000572c7c059c5b30ac Content-Type: text/plain; charset="UTF-8" Hi Mike, Thanks for your support, and yes, you're correct, I did mean to structure the type prior to the []. I'm unsure of exactly how this might work so defer to an Internals export, but having previously read @Nikita Popov 's great post on PHP's arrays, I did wonder if by knowing the data type within an array and that it'd conform to a strict structure, could the array itself be stored in an alternative way in C? Perhaps a more memory efficient way, or one that's faster to iterate over rather than just a hash table? Link to this article for reference: https://nikic.github.io/2012/03/28/Understanding-PHPs-internal-array-implementation.html Cheers, Aran On Fri, 17 Jan 2020 at 19:17, Mike Schinkel wrote: > > > On Jan 17, 2020, at 2:50 AM, Aran Reeks wrote: > > That said, there's a common use case that keeps me going back to them > which > > I think would be a good thing for PHP to try and solve as a language > > feature - better typing of arrays to type their properties. > > I for one would be a big +1 for this, with caveats. > > > IDEs like PHPStorm handle this structure already hence sticking to that > as > > a starting point... > > > > @returns []int > > As previously noted, I assume you meant int[]? > > ---- > > Having the ability to type array elements would cover ~90% of the cases > where I cannot properly type parameters or return values in PHP 7.4. > > The caveat is that it would seem that to check dynamically would be an > expensive proposition such as when an array that was not typed is passed to > or returned from a function or assigned to a variable of a declared type, > e.g. > > function foo( $myarray ): Foo[] { > return $myarray; // This would need to be dynamically checked, I > think? > } > > Of course we could limit this type of typing to only arrays that are > already know to be typed, meaning this would always fail: > > function bar( Foo[] $myarray ) { > // Do whatever > } > function baz( $myarray ) { > bar( $myarray ); // Fails here because $myarray not known to be > Foo[] even when it is > } > baz( [ new Foo() ] ); > > Alternately we could have a global option that would do type checking or > not for these type hints, so they could be dynamically checked for all code > prior to production code, where checking could be turned off. > > Another option could be if the number of array elements is small (<100?) > it could check, but otherwise not check, but this feels all kind of > different types of wrong. > > ---- > > My vote, if I had one, would be to add type new typing for array elements, > but also add a type checking global option that can be in one of 3 states: > > 1. Static checks only, > 2. Dynamic checks only, or > 3. No checking of array elements. > > #jmtcw > > -Mike > P.S. Or maybe there is an inexpensive way to keep track of the types of > the entire array on element assignment? > P.P.S. Can someone please explain and give an example of how generics > would make this need moot? I do not get why that would be the case... > > --000000000000572c7c059c5b30ac--