Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115094
MIME-Version: 1.0
In-Reply-To: <CAESVnVo78NNaOKCQt27y0AN6Jysw2DHFWUOoTkToh+Onj7EZUw@mail.gmail.com>
References: <012901d7683a$446a7ba0$cd3f72e0$@gmail.com> <CAESVnVrFX9MWBQZPnkas+hJBgatOsuT_g1wpOcDstcD09+qASg@mail.gmail.com>
 <C58053AC-0692-4E40-AEFB-D60893665588@newclarity.net> <CAESVnVo78NNaOKCQt27y0AN6Jysw2DHFWUOoTkToh+Onj7EZUw@mail.gmail.com>
Date: Thu, 24 Jun 2021 11:20:45 +0500
Message-ID: <CAC_PL4z_E8GzQdB=NfHthe8D7C5VvhvGSrq0dzjxvnzx_yzY3A@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Mike Schinkel <mike@newclarity.net>, "G. P. B." <george.banyard@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Introduce str_left/right In 8.1
From: office.hamzaahmad@gmail.com (Hamza Ahmad)

To George, et al,

HI George,

> I really don't see the point of these functions.

These functions provide a clearer semantics for their usage. Substr,
as Sara has mentioned, can be an alternative to these functions. Does
it make clear that substr returns the either ends of a string? No,
substr returns a part of a string, not ends. Although both mean
similar, and substr can be used in absence of these functions, saying
so is not linguisticly true!

If these functions are added, one can make sense of what these
functions actually do, without involving extra thought process.
Furthermore, it will help code readers decode their purpose at the
cognitive level, and that will provide with a faster understanding of
the code. Therefore, Microsoft is using AI to design a clearer
language to aid human minds understand quickly. I don't know how your
mind functions, but allow me to explain my thought process. When I see
substr, my mind says it is going to be a part of string from x offset
to y offset. Then, I look at the offsets, I learn that it is either
going to be a left end or a right end. If these functions are added to
PHP, programmers will have a clear idea of what is going on there
using a single thought. You are free to accuse me of mixing both
psychology and computer science.

HI Sara,

> you didn't explain what they're meant to actually do.

I thank you for pointing this out and also providing with the userland
examples of these functions. As for the second function, I myself some
time ago learnt that negative indexes are supported in substr. When I
wrote this function for the first time, I used some other technique.
As I have explained above that these functions are too common and
useful, I don't find any big issue if these functions are added to
core. IN VB, both mid and left/right functions exist.

Hi Guilliam,

> I think that's more about "semantics" ("conveying intent to readers") than typing...

True, this is the main objective and motivation. Please, see the
second paragraph that I dedicated to George.

Hello Mike,

> str_right() would provide an obvious solution that would be easy to find in IDE autocomplete or...

I thank you for adding to the discussion. When I first time felt the
need of str_right, I wrote this in a following way.
```
function right($str, $num) {
return substr($str, strlen($str) - $num);
};
``
Your opinion has strengthened my argument in three respects. First,
these functions are often searched for and wanted in the community.
Second, these functions will make the semantics clear. Third, these
functions are too clear in their signatures and purpose, and one would
hardly need to modify them. Nor, we need to add extra parameters and
introduce new behaviors, like JSON indentation RFC. As for multibyte
string functions, this is another domain. IF one wants to add mb_
these functions, it can also think of.

Hi Christoph,

> substr()  is about bytes, not characters.

Yes. Because PHP has MB string functions separately, implementation of
these functions will be once for all. There will hardly be a need of
touching these functions again.

Hi Rowan,

I thank you for providing with an other opinion. Here, I am only
talking about the basic string functions. As for the MB functions, I
am sure if these functions are added to core, they will also acquire
their place in mb_* functions list.

Because the time is approaching, what do you all suggest whether this
request requires an RFC?

I thank you all for providing me with your opinions. I wish this
thread leads a positive consensus.

Best
Hamza Ahmad


On 6/24/21, Sara Golemon <pollita@php.net> wrote:
> On Wed, Jun 23, 2021 at 2:10 PM Mike Schinkel <mike@newclarity.net> wrote:
>
>> I have frequently heard the justification of maintenance burden mentioned
>> as an objection to adding specific features.  And in many cases, it is
>> easy
>> to see why future maintenance burden would be a concern.
>>
>> However, it *seems* in this case that these functions are so trivial to
>> implement that once written and documented they would likely never need
>> to
>> be touched again. But as I do not yet know the internals of PHP I
>> obviously
>> do not know that to be a fact.
>>
>> Honest question: Would you mind explaining the type of maintenance
>> required for simple functions like this?  What is likely to change in the
>> future that would require maintenance?  And would you mind giving a few
>> or
>> at least one example of a trivial function that did need to be maintained
>> after it was written?
>>
>>
> Honest answer. I won't personally feel any pain from adding these
> functions. No more than I felt when str_contains() was added over my
> objections.  Nobody maintaining PHP will feel significant burden from
> them.  They'll sit in ext/standard/string.c doing their trivial work,
> opaque to the jit, and they'll get used or not.  If cluttering the kitchen
> sink with one more unwashed utensil makes someone happy, then fine.  I'm
> not going to vote for it though, because it belongs in composer/packagist
> land, not in core.  I've listed the reasons for this in the str_contains()
> threads, feel free to reference those, they're still valid and correct.
>
> -Sara
>
> P.S. - I don't actually think the octet versus codepoint versus grapheme
> argument can be particularly persuasive given that our core string
> functions aren't encoding aware in the slightest.  That ship has sailed.
> It is, however, another argument for doing this in userspace where the
> tradeoff is far more obvious, and dealing with alternative multibyte
> engines and/or polyfills is much more facile.
>