Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125172
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 23 Aug 2024 23:21:36 +0200
To: "Vincent Langlet" <mr.vincent.langlet@gmail.com>
Cc: internals@lists.php.net
Message-ID: <90955b3c-db6e-497d-8d20-4090eb0882bd@app.fastmail.com>
In-Reply-To: 
 <CABEW5qeqw70Yq6dw1MDKA1u9OTW7U1MdSibXTwPWGhXtq-oNVQ@mail.gmail.com>
References: 
 <CABEW5qdVYw3UqiUstV69eKyk1U293ztisFPanR+7kTCFu=9JGw@mail.gmail.com>
 <8307aee0-f7c2-4e30-9823-ed38e66d0c3a@app.fastmail.com>
 <CABEW5qeqw70Yq6dw1MDKA1u9OTW7U1MdSibXTwPWGhXtq-oNVQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] On the need of a `is_int_string` ?
Content-Type: multipart/alternative;
 boundary=cb1076cf6b90481a897008b1d398cda0
From: rob@bottled.codes ("Rob Landers")

--cb1076cf6b90481a897008b1d398cda0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Aug 23, 2024, at 23:10, Vincent Langlet wrote:
> I found a simpler implementation later which rely on array_keys
> ```
> fn is_int_string(string $s): bool =3D> \is_int(array_keys([$s =3D> nul=
l])[0]);
> ```
>=20
> I considered that `is_int_string` was better in the same namespace than
> `is_object`, `is_array`, `is_int`, `is_numeric`, ... but maybe there w=
as something better
>  than `int_string` to describe this category of string since english i=
s not good (integish ? integable ? integerable ?).
> But indeed it could be interesting to relate this method to the array =
namespace...

Don't forget to bottom post!

I'm curious which one is faster/more efficient. :)=20

> Anyway, this topic does not seems to interest lot of developer so far =
^^'

I think it would be worth writing an RFC for. While super-niche feeling,=
 I was literally bit by this the other day when storing what I thought w=
ere numbers as keys, but it turned out they got stored as strings (2-dig=
it numbers, and the zero-prefix bit me). That being said, I'm not sure h=
ow this function would have helped me (other than tossing in a few asser=
ts to make sure things were sane). So, writing an RFC will force you to =
think about usecases like that and some examples to highlight the issue =
it helps solve.

=E2=80=94 Rob
--cb1076cf6b90481a897008b1d398cda0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Fri, Aug 23, 2024, at 23:10, Vincent Langlet wrote:<br=
></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><=
div>I found a simpler implementation later which rely on array_keys<br><=
/div><div>```<br></div><div>fn is_int_string(string $s): bool =3D&gt; \i=
s_int(array_keys([$s =3D&gt; null])[0]);<br></div><div>```<br></div><div=
><br></div><div>I considered that `is_int_string` was better in the same=
 namespace than<br></div><div>`is_object`, `is_array`, `is_int`, `is_num=
eric`, ... but maybe there was something better<br></div><div>&nbsp;than=
 `int_string` to describe this category of string since english is not g=
ood (integish ? integable ? integerable ?).<br></div><div>But indeed it =
could be interesting to relate this method to the array namespace...<br>=
</div></div></blockquote><div><br></div><div><div>Don't forget to bottom=
 post!<br></div><div><br></div><div>I'm curious which one is faster/more=
 efficient. :)&nbsp;<br></div><div><br></div></div><blockquote type=3D"c=
ite" id=3D"qt" style=3D""><div dir=3D"ltr"><div>Anyway, this topic does =
not seems to interest lot of developer so far ^^'<br></div></div></block=
quote><div><br></div><div>I think it would be worth writing an RFC for. =
While super-niche feeling, I was literally bit by this the other day whe=
n storing what I thought were numbers as keys, but it turned out they go=
t stored as strings (2-digit numbers, and the zero-prefix bit me). That =
being said, I'm not sure how this function would have helped me (other t=
han tossing in a few asserts to make sure things were sane). So, writing=
 an RFC will force you to think about usecases like that and some exampl=
es to highlight the issue it helps solve.<br></div><div><br></div><div i=
d=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--cb1076cf6b90481a897008b1d398cda0--