Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124301 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 736BE1A009C for ; Mon, 8 Jul 2024 23:58:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720483215; bh=0E703ncIGt6FCI/N0e2bI0YSJfQheoc0XwiFE0Db9Ak=; h=From:Subject:Date:References:To:In-Reply-To:From; b=foC5eV0UXVLaylSjWXnD46rPljWA3cD+ImI1YK93BDB/kR0L4wRqrrqkdeCCUYx4N I2z7Smjl9VqCgahRhGca55/H+tvP+Bt1yBY5hVULT/vJ0DG6L//sKOTXy3BF2FYQkE uReb1tSoqdC7KMyHqvJiagWaPPoWbHVn/qaNTbhcQO+pLwAxbdFuC8n+QjBtikAkWV 9+eqmwpo+tg8yuUvk2TszBlt5ovOkgDMnw85rBHs0d72Wo3WawvvpJ+O8HG64UX9KP aVEnMovxixCvHrNOxnrLuut0o4Lf/KNYRSvZxxHUJ2XV3Ra/JheYwcs3QC1H8sBvVK LZJKqq/iVCPVQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 129FD18003F for ; Tue, 9 Jul 2024 00:00:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 9 Jul 2024 00:00:13 +0000 (UTC) Received: by mail-il1-f181.google.com with SMTP id e9e14a558f8ab-37636c3872bso18081665ab.3 for ; Mon, 08 Jul 2024 16:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miles.systems; s=google; t=1720483126; x=1721087926; darn=lists.php.net; h=message-id:in-reply-to:to:references:date:subject:mime-version:from :from:to:cc:subject:date:message-id:reply-to; bh=lvZNVP8WBBHLVOFKVAI0Q7IOqrLjgkQRH3rkIUcSWpo=; b=Brj5O80FPUa6jzaChRoCGKaHTAOGoea8naciauR1uRzCTBjjTkVfYOGt0gSZpdurbi fQedptwK2wL7nsWyBSjCDSRLyVwlYDRkPoXYWs0DHMw0RAKrjbUUkIUnVId9M1+RELAX GB9MSIKVzXtJwPV2DiOgsnH+upASe37rVwir1viO5bia2BqFptz/JLfJBtv2k0mhuYRR QrKB9Ll5xN61o0PFmgeLAVFZJzljcDIPBfRv/ppSIPnEKl+TLBv/d/cQzKuWbRN12kpy DxGugbvkFYiG1S95rnRFiqPnO4wWoY+KjBuohVpA5yyfGgK59C8xkU95qreM6fiCCjYv Cg3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720483126; x=1721087926; h=message-id:in-reply-to:to:references:date:subject:mime-version:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lvZNVP8WBBHLVOFKVAI0Q7IOqrLjgkQRH3rkIUcSWpo=; b=BXcDGc5uhuBBXxr0CAewSsc+bVZisZh9V4cZn6m4FkDp648vOe+IAtqjA9MyzjxAkw qo+QR9HQFzoCC/ajzEiLORbYnBCMzWW3mVw9o5eoS++awMuJKP/+gyXBG/gxPqMsn2d5 DLibF0S8h++ndtRp2pR2Chh6i4B4ztBhTDqWECfWV9h4UVkdyWe9AAcuChddynR0p4R5 Vi7IpX4ytK6165lAsy/OM6bzGbpYbOOdCry7wApGlgAul/kK4lyuFVQIhQcE9l2bGgA4 bDa78ByLT3T5rQ0IMgnJC3LiFpSwpv5hG0hFSQbeSAb77bxrVrYs+5HIt12pKuQDBOPv YWKg== X-Gm-Message-State: AOJu0Yw9ho/aOl/YTo+8xXNFOWdwxChWo6zHLAM5rzoqknFIPMiFdVSE wCMw2F9NZ/KoyY3/jgNpqVYcB/awXoXaY2QXjg8wu7LfD5EODa/lADfm4N00S6SkJMGp3NKeNFC UfqcGhpywXWpDM9WLvu8gtkLzNUpWPPGGcLiMlt2pmtSnCGSerPyNylSCGzceRScAONWQIaYJON LJjCsjYVRHy8veQFv5/toI14c45hRy3L1fLAEeTr71 X-Google-Smtp-Source: AGHT+IEAOWGRos1Tqwt3a7vGwTIoXIgS+y26cjj8IBbC40XaAWBWbek74YZMPG/JuW7IKozKA72neA== X-Received: by 2002:a05:6e02:1a63:b0:375:c394:567a with SMTP id e9e14a558f8ab-38a56d0c2efmr13171265ab.7.1720483126191; Mon, 08 Jul 2024 16:58:46 -0700 (PDT) Received: from smtpclient.apple (c-67-161-146-209.hsd1.co.comcast.net. [67.161.146.209]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-38a4be43543sm1785925ab.84.2024.07.08.16.58.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2024 16:58:45 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5C9FC3F1-6712-4A54-A309-EC52D4E60AF0" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [PHP-DEV] [Initial Feedback] Typed Arrays Date: Mon, 8 Jul 2024 17:58:33 -0600 References: <07A8534A-1B45-4F15-A78B-AA7DDF92B8B6@koalephant.com> <5BA404A4-7281-475F-A1F6-D1252ABB059D@miles.systems> <39B8662A-FD7D-467A-883C-E8D71B5A4E02@miles.systems> To: php internals In-Reply-To: <39B8662A-FD7D-467A-883C-E8D71B5A4E02@miles.systems> Message-ID: X-Mailer: Apple Mail (2.3774.600.62) From: richard@miles.systems (Richard Miles) --Apple-Mail=_5C9FC3F1-6712-4A54-A309-EC52D4E60AF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Howdy people, > On Jul 1, 2024, at 10:01=E2=80=AFAM, Richard Miles = wrote: >=20 > Hey Larry,=20 >=20 >>> interface iArrayA ['a' =3D> string ] >>> interface iArrayB extends iArrayA ['b' =3D> string, 'c' =3D> = ?string, =E2=80=98d=E2=80=99=20 >>> =3D> SomeClass, =E2=80=98e=E2=80=99=3D> iArrayA, =E2=80=98f=E2=80=99= =3D> mixed ] >>> $array =3D (iArrayA &| iArrayB) [ =E2=80=98a=E2=80=99 =3D> = =E2=80=98hello=E2=80=99 ]; >=20 > I will start by advocating for how much cleaner this is from its = objective counterpart. It also aids in reusability. >=20 >> As Stephen already said, we have this already. It's spelled like = this: >>=20 >> class A { >> public function __construct(public string $a) {} >> } >>=20 >> class B extends A { >> public function __construct( >> public string $a,=20 >> public string $b,=20 >> public ?string $c, >> public SomeClass $d, >> public A $e, >> mixed $f, >> ) {} >> } >>=20 >> If you know the keys at code time, use a class, not an array. Full = stop, period, end of story. Using an array as a record object in PHP >=3D= 7 *is wrong*. It's slower, more memory-intensive, less ergonomic, = harder to debug, harder to statically analyze, harder to learn, harder = to use. If you're still doing that, it's past time to stop. If your = legacy application from the PHP 3 days is still doing that, it's past = time to upgrade it. >=20 >=20 > I feel this is a common misconception, or can you clarify this for me?=20= > Array access is faster than object access.=20 > I didn=E2=80=99t want to claim this without first running the = benchmarks: >=20 > = https://github.com/EFTEC/php-benchmarks/blob/master/benchmark_array_vs_obj= ect.php > Good news is these benchmarks already exist! I just cloned this repo, = required the table builder, and profit. >=20 > composer require eftec/mapache-commons > php benchmark_array_vs_object.php > ... > To save you the trouble you can refer to this Medium post: > https://medium.com/cook-php/php-benchmark-time-fc19d813aa98 >=20 > I figured you=E2=80=99d say something about the =E2=80=99newest=E2=80=99= syntax so I added=20 > class DummyClass > { > public function __construct(public $hello, public $second, public = $third) > { > } > } > Thus, my results are as follows: >=20 > Array numeric no factory: 0% baseline at 0.414 = (mind you im on an older MacBook) > Array no factory 0.95% > Array numeric factory: 566.1% > Array factory: 650.07% > Object Constructor: 609.03% > Object no constructor 82.77% > Object no constructor setter/getter: 2058.43% > Object no constructor magic methods: 2273.91% > Object no constructor stdClass: 112.53% >=20 > These were pretty consistent with the medium post. >=20 >> So new language features to make "misuse arrays as objects" easier = are actively counter-productive. >>=20 >> A Dict / Hashmap is appropriate when you do *not* know the keys in = advance, and thus cannot use a pre-defined object for it. There are = plenty of use cases for that, but in that case, all you need type-wise = is the key type and value type, because all entries should be of the = same type (give or take inheritance). Mixing in random other types... = is wrong. That's the whole reason why people keep talking about = collections/typed arrays/generics. >=20 >=20 >=20 > I think the point we can take away from this is that we could=20 > speed arrays up even more if we make typed arrays stricly bound and = not a =E2=80=98hash=E2=80=99.=20 > If we knew the keys in advance then in theroy we could make access = based on the=20 > numeric value of that property in the interface definition. > But as I keep saying this is worth investigating.=20 >=20 >> So the "array interface" syntax you keep posting is actively = counter-productive. >=20 > I=E2=80=99m absolutely just trying to help while I have an abundance = of free time. I do admit to been > a n00b sometimes. If something isn=E2=80=99t fast lets talk about how = we might make it faster.=20 > I don=E2=80=99t think anyone disagrees with you in that this is a big = undertaking that shouldn=E2=80=99t be=20 > taken lightly, but the community is strong and we=E2=80=99ll manage, = even if at a turtles pace :) >=20 > If my understanding above is correct then Larry=E2=80=99s message = actually highlights why we=20 > should implement this feature. The community thinks objects are the = way to go,=20 > since its the only way to go. >=20 > Best, > Richard Miles So since im not getting any feedback about the above, we can concrete = the fastness of array over objects access. I=E2=80=99m ready to make this Syntax Proposal RFC but still need RFC = karma.=20 Could someone please give my wiki.php.net account = access: wookieetyler Best, Richard Miles --Apple-Mail=_5C9FC3F1-6712-4A54-A309-EC52D4E60AF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Howdy = people,

On Jul 1, 2024, at 10:01=E2=80=AFA= M, Richard Miles <richard@miles.systems> wrote:

Hey = Larry, 

interface iArrayA ['a' = =3D> string ]
interface iArrayB extends iArrayA ['b' =3D> = string, 'c' =3D> ?string, =E2=80=98d=E2=80=99
=3D> =  SomeClass, =E2=80=98e=E2=80=99=3D>  iArrayA, =E2=80=98f=E2=80= =99 =3D> mixed ]
$array =3D (iArrayA &| iArrayB) [ =E2=80=98a=E2= =80=99 =3D> =E2=80=98hello=E2=80=99 = ];

I will = start by advocating for how much cleaner this is from its objective = counterpart. It also aids in reusability.

As Stephen already said, we have this already. =  It's spelled like this:

class A {
 public function = __construct(public string $a) {}
}

class B extends A {
=  public function __construct(
   public string = $a,
   public string $b,
=    public ?string $c,
   public = SomeClass $d,
   public A $e,
=    mixed $f,
 ) {}
}

If you know the = keys at code time, use a class, not an array.  Full stop, period, = end of story.  Using an array as a record object in PHP >=3D 7 = *is wrong*.  It's slower, more memory-intensive, less ergonomic, = harder to debug, harder to statically analyze, harder to learn, harder = to use.  If you're still doing that, it's past time to stop. =  If your legacy application from the PHP 3 days is still doing = that, it's past time to upgrade = it.


I feel = this is a common misconception, or can you clarify this for = me? 
Array access is faster than object = access. 
I didn=E2=80=99t want to claim this without = first running the benchmarks:

Good news is these = benchmarks already exist! I just cloned this repo, required the table = builder, and profit.

composer require = eftec/mapache-commons
php = benchmark_array_vs_object.php
...
To save you the = trouble you can refer to this Medium post:
<= a style=3D"border-radius:10px;font-family:-apple-system, Helvetica, = Arial, = sans-serif;display:block;-webkit-user-select:none;width:300px;user-select:= none;-webkit-user-modify:read-only;user-modify:read-only;overflow:hidden;t= ext-decoration:none;" class=3D"lp-rich-link" rel=3D"nofollow" = href=3D"https://medium.com/cook-php/php-benchmark-time-fc19d813aa98" = dir=3D"ltr" role=3D"button" draggable=3D"false" width=3D"300">
<0*gG1FcLJE3h2vybWa.jpe= g>

I = figured you=E2=80=99d say something about the =E2=80=99newest=E2=80=99 = syntax so I added 
class =
DummyClass
{
    =
public function =
__construct(public $hello, public $second, public =
$third)
    {
    }
}
Thus, my results are as = follows:

Array numeric no factory: = 0%   baseline at 0.414 (mind you im on an older = MacBook)
Array no factory = 0.95%
Array numeric factory: = 566.1%
Array factory: = 650.07%
Object Constructor: = 609.03%
Object no constructor = 82.77%
Object no constructor setter/getter:  = 2058.43%
Object no constructor magic methods: = 2273.91%
Object no constructor stdClass:  = 112.53%

These were pretty consistent = with the medium post.

So new language features to make "misuse arrays as = objects" easier are actively counter-productive.

A Dict / Hashmap = is appropriate when you do *not* know the keys in advance, and thus = cannot use a pre-defined object for it.  There are plenty of use = cases for that, but in that case, all you need type-wise is the key type = and value type, because all entries should be of the same type (give or = take inheritance).  Mixing in random other types... is wrong. =  That's the whole reason why people keep talking about = collections/typed = arrays/generics.


= I think the point we can take away from this is that we = could 
speed arrays up even more if we make typed arrays = stricly bound and not a =E2=80=98hash=E2=80=99. 
If we = knew the keys in advance then in theroy we could make access based on = the 
numeric value of that property in the interface = definition.
But as = I keep saying this is worth = investigating. 

So the "array interface" syntax you keep posting is = actively counter-productive.

I=E2=80=99m = absolutely just trying to help while I have an abundance of free time. I = do admit to been
a n00b sometimes. If something isn=E2=80=99t = fast lets talk about how we might make it faster. 
I = don=E2=80=99t think anyone disagrees with you in that this is a big = undertaking that shouldn=E2=80=99t be 
taken lightly, but = the community is strong and we=E2=80=99ll manage, even if at a turtles = pace :)

If my understanding above is correct = then Larry=E2=80=99s message actually highlights why = we 
should implement this feature. The community thinks = objects are the way to go, 
since its the only way to = go.

Best,
Richard = Miles

So since = im not getting any feedback about the above, we can concrete the = fastness of array over objects access.

I=E2=80=99= m ready to make this Syntax Proposal RFC but still need RFC = karma. 

Could someone please give = my wiki.php.net account = access: wookieetyler

Best,
Richard = Miles


= --Apple-Mail=_5C9FC3F1-6712-4A54-A309-EC52D4E60AF0--