Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126768
Precedence: bulk
MIME-Version: 1.0
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
 <811B65CE-1DF0-4A47-937C-4FCB6E945B92@pmjones.io> <cf16068b3acf6692172ee0971fcda417@bastelstu.be>
 <19377F60-FB7F-4E6E-A085-4DCB6CD92234@pmjones.io> <da26554a-ed39-4e80-bcb4-29a46d9fdb61@gmail.com>
 <7B7987C6-37F3-432A-8BA2-9D93F428FAD5@pmjones.io> <CAMkukMw4V0YopJZbapczApH1h5ssKh_5yCEh5KCHSnDGiwTKzw@mail.gmail.com>
 <93898e96-bbd6-4c2e-a1ad-35499bb2510d@app.fastmail.com> <CANS-=pd4p8SQmW4TE+FfhNCUE0zRi+m2NXeZpRvCLJRz9kYizQ@mail.gmail.com>
In-Reply-To: <CANS-=pd4p8SQmW4TE+FfhNCUE0zRi+m2NXeZpRvCLJRz9kYizQ@mail.gmail.com>
Date: Fri, 14 Mar 2025 22:41:28 +0100
Message-ID: <CAH5C8xVaCqOsEx7m3JuLkxt8KA1K=WDUgTZ+_UdzrZXBpShb9w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: Lynn <kjarli@gmail.com>
Cc: Rob Landers <rob@bottled.codes>, Faizan Akram Dar <hello@faizanakram.me>, 
	"Paul M. Jones" <pmjones@pmjones.io>, ignace nyamagana butera <nyamsprod@gmail.com>, 
	=?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	"Gina P. Banyard" <internals@gpb.moe>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c190b50630544d5b"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000c190b50630544d5b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Depends on there being the intention to have it as parameter type. If it's
> designed to be passed around to functions I really don't want it to be an
> array. I am maintaining a legacy codebase where arrays are being used as
> hashmaps pretty much everywhere, and it's error prone. We lose all kinds =
of
> features like "find usages" and refactoring key/property names. Silly typ=
os
> in array keys with no actual validation of any kind cause null values and
> annoying to find bugs.
>
> I agree that hashmaps can be really easy to use, but not as data
> structures outside of the function/method scope they were defined in. If
> value vs object semantics are important here, then something that is
> forward compatible with whatever structs may hold in the future could be
> interesting.
>

Yes, I agree here, even if we talk about simple data without behavior. But
as the length of the current RFC also suggests, URIs have surprisingly lot
of behavior, so I think it's natural to use OO for modelling them.

M=C3=A1t=C3=A9

--000000000000c190b50630544d5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div class=3D"gmail_quote gma=
il_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(77,77,77);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div>Depends on there being the intenti=
on to have it as parameter type. If it&#39;s designed to be passed around t=
o functions I really don&#39;t want it to be an array. I am maintaining a l=
egacy codebase where arrays are being used as hashmaps pretty much everywhe=
re, and it&#39;s error=C2=A0prone. We lose all kinds of features like &quot=
;find usages&quot; and refactoring key/property names. Silly typos in array=
 keys with no actual validation of any kind cause=C2=A0null values and anno=
ying to find bugs.</div><div><br></div><div>I agree that hashmaps=C2=A0can =
be really easy to use, but not as data structures outside of the function/m=
ethod scope they were defined in. If value vs object semantics are importan=
t here, then something that is forward compatible with whatever structs may=
 hold in the future could be interesting.</div></div></div></blockquote><di=
v><br></div><div>Yes, I agree here, even if we talk about simple data witho=
ut behavior. But as the length of the current RFC also suggests, URIs have =
surprisingly lot of behavior,=C2=A0so I think it&#39;s natural to use OO fo=
r modelling them.</div><div><br></div><div>M=C3=A1t=C3=A9</div></div></div>

--000000000000c190b50630544d5b--