Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116095 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38858 invoked from network); 19 Sep 2021 03:06:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Sep 2021 03:06:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 452EF1804E3 for ; Sat, 18 Sep 2021 20:47:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE,YOU_INHERIT 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-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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 ; Sat, 18 Sep 2021 20:47:17 -0700 (PDT) Received: by mail-qt1-f178.google.com with SMTP id o10so2248213qtk.0 for ; Sat, 18 Sep 2021 20:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zz7eBRFvyzw/MHiqBPOaGVceuCYY9DqhyFUssLLaZd8=; b=r6e1WdsBaeE01jW/QrNdtqT9WVP0aoltCH1wGJIuH7bXbUGlxAG/GBhGxOoGKSGTAQ SdB/PWjsck7cMwGIjtCCFTRN1DZfl0WGx33bZs5NaZunJHuqNv7M2nLTAHsY6xTKxPUW 62SRvlL5qkvlX/Gd7zvVou5QPm4fHYif4N2xWybnM29PCVelz+rox2gxRtGbtUDWAu4z 7VeWcJPCWhhMT/gdmaCNl1wXF6B1j2xMH4Ocw/ZXhcCcEQZzMsvA2ptMEOeV40ft2KHG Xt1tz018LgF9he/QIsi7VGxebcbQMoNGop5dgQuNvDEfh+674tNA6W6Vq9TPsKZzEaSv LqsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zz7eBRFvyzw/MHiqBPOaGVceuCYY9DqhyFUssLLaZd8=; b=jEvbIDZLKwl8uysT59KJeCJx8obUXfo1GtkY19BcfqP3YTTf1N34nMnp/fUJrrZxf7 3mOBlwGq0cZBgYx+wvmCflCVDaH6tG+s1yKqdqU0cynfrOZ2bQ1u0syH49G8/zxLOKMr 2u/0t867QJLMzNnhTumensATnN2FDcAe9DTwJ64NLcLfYxJm3Lf8Gc4iY71bXLjqOIar jg8IQrTDcu40rSqwZeBwzlHdDZzQHgO91Y0ZlbPfZOpeFPaa+xYFHlrVHOgpKTWD7Z2V Q2Daub5SBESAo/AME9khjBnPy8v7GcZUIyeQSqxO721g3cs8GF0kaO/t5NaoVIZeyt4p yuQg== X-Gm-Message-State: AOAM531UEGEXm3cWzMhNJlXcBYWX3Pzx4uV0F+OiqJ29PrWhMAwT09Wl a2TEawWFzvA6AcxqOfTSGdIZ6Q== X-Google-Smtp-Source: ABdhPJxUxDRnOSl3cI2jLbKFsteDBr6r47Ofxad/TPUZ/mAqiJclvR20JjQK+/TflenrKhDsyHiO9g== X-Received: by 2002:ac8:76d4:: with SMTP id q20mr4623583qtr.312.1632023236993; Sat, 18 Sep 2021 20:47:16 -0700 (PDT) Received: from [192.168.1.10] (c-24-98-254-8.hsd1.ga.comcast.net. [24.98.254.8]) by smtp.gmail.com with ESMTPSA id z12sm6691700qti.58.2021.09.18.20.47.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Sep 2021 20:47:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) In-Reply-To: Date: Sat, 18 Sep 2021 23:47:15 -0400 Cc: "internals@lists.php.net" Content-Transfer-Encoding: quoted-printable Message-ID: <8D04483B-8603-4C07-AB7A-D664C93F2BAB@newclarity.net> References: To: tyson andre X-Mailer: Apple Mail (2.3608.120.23.2.7) Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP From: mike@newclarity.net (Mike Schinkel) Hi Tyson, Thanks for the reply. > On Sep 18, 2021, at 7:26 PM, tyson andre = wrote: >=20 > Hi Mike Schinkel, >=20 >> Given there seems to be a lot of concern about the approach the RFC = proposes would it not address the concerns about memory usage and = performance if several methods were added to SplFixedArray instead (as = well as functions like indexOf(), contains(), map(), filter(), = JSONSerialize(), etc., or similar): >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> setCapacity(int) =E2=80=94 Sets the Capacity, i.e. the maximum Size = before resize >> getCapacity():int =E2=80=94 Gets the current Capacity. >>=20 >> setGrowthFactor(float) =E2=80=94 Sets the Growth Factor for push(). = Defaults to 2 >> getGrowthFactor():float =E2=80=94 Gets the current Growth Factor >>=20 >> pop([shrink]):mixed =E2=80=94 Returns [Size] then subtracts 1 from = Size. If (bool)shrink passed then call shrink(). >> push(mixed) =E2=80=94 Sets [Size]=3Dmixed, then Size++, unless = Size=3DCapacity then setSize(n) where n=3Dround(Size*GrowthFactor,0) = before Size++. >>=20 >> grow([new_capacity]) =E2=80=94 Increases memory allocated. Sets = Capacity to Size*GrowthFactor or new_capacity. >> shrink([new_capacity]) =E2=80=94 Reduces memory allocated. Sets = Capacity to current Size or new_capacity. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> If you had these methods then I think you would get the memory and = performance improvements you want, and if you really want a final Vector = class for your own uses you could roll your own using inheritance or = containment. >=20 > I asked 8 months ago about `push`/`pop` in SplFixedArray. The few = responses were unanimously opposed to SplFixedArray being repurposed = like a vector, the setSize functionality was treated more like an escape = hatch and it was conceptually for fixed-size data. Hmm. I must have missed that thread as I was definitely following the = list at that time.=20 But I found the thread, which only had three (3) comments from others: https://externals.io/message/112639 =46rom Levi Morrison it seems his objection was to adding `push()` and = `pop()` to a class including the name "Fixed." Levi suggested = soft-deprecating `SplStack` because it was implemented as a linked-list, = but he proposed adding `Spl\ArrayStack` or similar, so it seems he was = open to iterating on the `Spl` classes in general (no pun intended.)=20 =46rom Nikita is seemed that he did not object so much as comment on = Levi's suggestion of adding `Spl\ArrayStack` and suggested instead an = `SqlDeque` that would handle queue usage more efficiently that plain PHP = arrays. So I think those responses were promising, but that you did not followed = up on them. I mean no disrespect =E2=80=94 we all get busy, our = priorities change, and things fall off our radar =E2=80=94 but it feels = to me like you might have more success pursing your use-cases related to = the `Spl` classes than via a pure `Vector` class. Maybe propose an = `SplVector` class that extends `SplFixedArray`, or something similar = that addresses the use-case and with a name that people can agree on? BTW, here are two other somewhat-related threads: - https://externals.io/message/110731 - https://externals.io/message/113141 > I also believe adding a configurable growth factor would be excessive = for a high level language. I wavered on whether or not to propose a configurable growth factor, but = ironically I did so to head off the potential complaint from anyone who = cares deeply about memory usage (isn't that you?) that not allowing the = growth factor to be configurable would mean that either the class would = use too much memory for some use-cases, or would need to reallocate more = memory too frequently for other use-cases, depending on what the default = growth factor would be. That said, I don't see how a configurable growth factor should be = problematic for PHP? For those who don't need/care to optimize memory = usage or reallocation frequency they can simply ignore it; no harm done. = But for those who do care, it would give them the ability to fine tune = their memory usage, which for selected use-cases could mean the = difference between being able to implement something in PHP, or not. Note that someone could easily argue that adding a memory-optimized data = structure when we already have a perfectly flexible data structure with = PHP arrays that can be used for the same algorithms is "excessive for a = high-level language." But then I don't think you would make that = argument, so why make it for a configurable growth factor? = #honestquestion > This has been asked about multiple times in threads on unrelated = proposals (https://externals.io/message/112639#112641 and = https://externals.io/message/93301#93301 years ago) throughout the = years, but the maintainer of php-ds had a long term goal of developing = the separately from php's release cycle (and was still focusing on the = PECL when I'd asked on the GitHub issue in the link almost a year ago). And finally I think when you conveyed the intent of the author of = `ext-ds` you omitted part of his full statement. When seen in full I = believe his statement conveys a different interest than the partial one = implies: https://github.com/php-ds/ext-ds/issues/156 While he did say "My long-term intention has been to not merge this = extension into php-src" he immediately also said "I would like to see it = become available as a default extension at the distribution level."=20 Based on his full statement I assume that an RFC that would propose = adding an uncommented `extension=3Dext-ds.so` in the default `php.ini` = would have the author of ext-ds' backing. Assuming 2/3rd of voters would = agree, that seems like a really easy lift, implementation-wise? Adding an apparently well-respected extension to default `php.ini` and = mentioning in the release notes so that userland PHP developers would = become aware of it, start using it, writing blog posts about it, and = asking questions on StackOverflow about it would be a net plus. And = those who use managed PHP hosts that stick with the officially-blessed = extensions would actually finally have access to it; those who use = WordPress managed hosts, for example.=20 Of course including it would not preclude adding new data structures = into core in the future. Heck, with more people using `ext-ds` there = will likely be greater awareness of such functionality and better = recognition of its short-comings =E2=80=94 assuming it has them =E2=80=94 = and thus facilitate more interest in adding better data structures to = PHP core later on. Also, I noticed in that 5-year old link you referenced that a few vocal = members on the list bikeshedded over some of the finer details of the = `ext-ds` API. If an RFC to include `ext-ds` in `php.ini` were to be = submitted I would implore those people and others to consider that this = is the inclusion of an extension to `php.ini` and not a feature in PHP = core, and thus to please not let the perfect be the enemy of the good. =3D=3D=3D=3D=3D Given the above, I think you have one of two (2) potential directions to = pursue (or both) that each might bring more fruit than the RFC discussed = on this thread: 1. Propose an additional Spl class. 2. Propose addition of ext-ds to the default php.ini -Mike >=20 > I also believe adding a configurable growth factor would be excessive = for a high level language. >=20 > Thanks, > Tyson >=20 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >=20