Howdy people,

> On Jul 1, 2024, at 10:01 AM, Richard Miles <richard@miles.systems> wrote:
> 
> Hey Larry, 
> 
>>> interface iArrayA ['a' => string ]
>>> interface iArrayB extends iArrayA ['b' => string, 'c' => ?string, ‘d’ 
>>> =>  SomeClass, ‘e’=>  iArrayA, ‘f’ => mixed ]
>>> $array = (iArrayA &| iArrayB) [ ‘a’ => ‘hello’ ];
> 
> 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 >= 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’t want to claim this without first running the benchmarks:
> 
> https://github.com/EFTEC/php-benchmarks/blob/master/benchmark_array_vs_object.php
> 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:
> https://medium.com/cook-php/php-benchmark-time-fc19d813aa98
> 
> I figured you’d say something about the ’newest’ 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 
> ‘hash’. 
> 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’m absolutely just trying to help while I have an abundance of free time. I 
> do admit to been
> a n00b sometimes. If something isn’t fast lets talk about how we might make 
> it faster. 
> I don’t think anyone disagrees with you in that this is a big undertaking 
> that shouldn’t be 
> taken lightly, but the community is strong and we’ll manage, even if at a 
> turtles pace :)
> 
> If my understanding above is correct then Larry’s 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’m ready to make this Syntax Proposal RFC but still need RFC karma. 

Could someone please give my wiki.php.net <http://wiki.php.net/> account 
access: wookieetyler

Best,
Richard Miles


Reply via email to