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
php-benchmarks/benchmark_array_vs_object.php at master · EFTEC/php-benchmarks
github.com
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
PHP, Benchmark time
medium.com
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
