Re: [PHP-DEV] RFC karma request

[Ilija Tovilo]

Hi Valentin

On Thu, Dec 28, 2023 at 1:31 PM Valentin Udaltsov
 wrote:
>
> I kindly request RFC Karma for my wiki account vudaltsov. I am planning to
> publish RFC "new MyClass()->method() without parentheses". I already
> created a PR, where I got generally positive feedback on this feature:
> https://github.com/php/php-src/pull/13029

RFC karma was granted. Good luck!

Ilija

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC karma request

[Valentin Udaltsov]

Hi internals,


I kindly request RFC Karma for my wiki account vudaltsov. I am planning to
publish RFC "new MyClass()->method() without parentheses". I already
created a PR, where I got generally positive feedback on this feature:
https://github.com/php/php-src/pull/13029


Regards, Valentin

Re: [PHP-DEV] RFC Karma request

[Ilija Tovilo]

Hi Daniil

On Tue, Oct 17, 2023 at 8:25 PM Daniil Gentili  wrote:
> I'd like to create RFCs at least for final anonymous classes
> (https://externals.io/message/121356) and a small tweak to JIT defaults
> (https://externals.io/message/121359).
>
> Please give me RFC Karma :)
>
> Username: danog

RFC karma was granted, good luck with your RFC!

Ilija

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC Karma request

[Daniil Gentili]

Hi, internals.

I'd like to create RFCs at least for final anonymous classes 
(https://externals.io/message/121356) and a small tweak to JIT defaults 
(https://externals.io/message/121359).


Please give me RFC Karma :)

Username: danog

Kind regards,
Daniil Gentili.

--

GitHub: https://github.com/danog

--

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Karma Request

[Ilija Tovilo]

Hi Yuya

RFC karma was granted, good luck with your RFC!

Ilija

On Tue, Oct 17, 2023 at 5:07 PM youkidearitai  wrote:
>
> Hi, internals.
>
> I writing to trim for multibyte support function, mb_trim, mb_ltrim
> and mb_rtrim.
> https://github.com/php/php-src/pull/12459
>
> Please give me RFC Karma.
> Username: youkidearitai
>
> Regards.
> Yuya
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC Karma Request

[youkidearitai]

Hi, internals.

I writing to trim for multibyte support function, mb_trim, mb_ltrim
and mb_rtrim.
https://github.com/php/php-src/pull/12459

Please give me RFC Karma.
Username: youkidearitai

Regards.
Yuya
-- 
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC Karma Request: deprecation of ISO_8601 constants

[Jorg Sowa]

Hello,
I would like to request for RFC Karma.

I want to create RFC for deprecation of constants ISO_8601.

My wiki account is jorg_sowa.

Kind regards,
Jorg

Re: [PHP-DEV] RFC Karma Request: nameof proposal

[Robert Landers]

On Thu, May 4, 2023 at 10:52 AM Tim Düsterhus  wrote:
>
> Hi
>
> On 5/4/23 10:39, Robert Landers wrote:
> > I'd like to request RFC Karma for adding a nameof operator to PHP.
>
> That requires a Wiki account which you likely weren't yet able to
> create, due to the unsuccessfulness. We would also need your username.
>
> > Also, I attempted to register an account on the RFC website but was
> > unsuccessful:
> >
> >> That wasn't the answer we were expecting
> >
> > is the error message I received, but the form appears to be filled out
> > correctly.
>
> The logic for the check is given in this file:
> https://github.com/php/web-wiki/blob/master/dokuwiki/lib/plugins/phpreg/action.php.
> As of March 31st it should be fixed to work correctly to my understanding.
>
> Best regards
> Tim Düsterhus

Hey Tim,

Thanks, I see... the question wasn't very clear (at least to me), it
seemed like it was asking for me to confirm my email address not the
list's email address. Anyway, I now have an account.

Username: withinboredom
Email: this one

Thanks in advance

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Karma Request: nameof proposal

[Tim Düsterhus]

Hi

On 5/4/23 10:39, Robert Landers wrote:

I'd like to request RFC Karma for adding a nameof operator to PHP.


That requires a Wiki account which you likely weren't yet able to 
create, due to the unsuccessfulness. We would also need your username.



Also, I attempted to register an account on the RFC website but was
unsuccessful:


That wasn't the answer we were expecting


is the error message I received, but the form appears to be filled out
correctly.


The logic for the check is given in this file: 
https://github.com/php/web-wiki/blob/master/dokuwiki/lib/plugins/phpreg/action.php. 
As of March 31st it should be fixed to work correctly to my understanding.


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC Karma Request: nameof proposal

[Robert Landers]

Hello,

I'd like to request RFC Karma for adding a nameof operator to PHP.

Also, I attempted to register an account on the RFC website but was
unsuccessful:

> That wasn't the answer we were expecting

is the error message I received, but the form appears to be filled out
correctly.

Robert Landers
Software Engineer
Utrecht NL

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC karma request

[Ilija Tovilo]

Hi Niels

> I would like to gain RFC karma for creating and proposing an RFC: "Implement 
> GH-9673: $length argument for fpassthru".
> Account name: nielsdos

Christoph has granted you RFC karma. Good luck with the RFC!

Ilija

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC karma request

[Niels Dossche]

On 12/02/2023 15:46, Thomas Hruska wrote:
> On 2/12/2023 5:47 AM, Hans Henrik Bergan wrote:
>> Fwiw I would also find an $offset argument useful. fpassthru's lack of both
>> $length and $offset made my life harder when implementing "HTTP 206 Partial
>> Content" / "HTTP range requests",
> 
> I was going to suggest this myself until I realized that an $offset parameter 
> would be rather problematic.  What happens if the offset is negative?  Does a 
> negative offset mean seek backwards from the current position OR start at 
> that many bytes from the end of the stream?  Is the offset a seek operation 
> or a read operation?  Not all streams are seekable and reading is generally a 
> fairly slow, blocking I/O operation.  Also, not all stream lengths are known. 
>  A negative offset in non-seekable scenarios would almost certainly have to 
> throw an error. fseek()/fread() are more flexible and consistent for getting 
> to the desired starting point in a source stream.
> 

A negative offset would not be valid, just like it is not valid for 
stream_copy_to_stream.
The offset is a seek operation just like is the case for stream_copy_to_stream.
Not all streams are seekable that's true, but the programmer using the changed 
fpassthru function would have the same issue if they were to use fseek or 
stream_copy_to_stream.

> A negative $length would also present some issues.  Again, not all stream 
> lengths are known.  Correctly handling negative values would require managing 
> an internally, temporarily allocated buffer of sufficient size to be able to 
> backtrack streams of unknown length.  And might even have to cache the entire 
> stream in RAM, which would be problematic for 1GB+ streams.  Or just throw an 
> error for such streams. Or just restrict $length to non-negative values only.
> 
> In short, a non-negative, nullable $length parameter is the only well-defined 
> operation for fpassthru().
> 

The behaviour of a negative $length would be the same as for 
stream_copy_to_stream.
The current behaviour for negative lengths < -1 is to interpret them as 
unsigned lengths.
For lengths == -1 the behaviour is to copy everything.
I don't see how this is different from for example very large lengths and an 
unknown stream length.
I don't really understand your concern here. Could you please elaborate on the 
problem you see?

> fpassthru() is largely a convenience wrapper around fread()/unbuffered echo 
> in a loop with some extra output buffer management and is subject to PHP 
> max_execution_time.  For large files and/or slow/high latency networks, PHP 
> can timeout before delivering all content.
> 
> There are several web server extensions available (X-Sendfile and 
> X-Accel-Redirect) where, for local files, the rest of the request can be 
> handed off from PHP to the web server to completely avoid writing any file 
> output to the output buffer and also avoid timeout issues.  The existence of 
> modern web server extensions for all major web servers limits the overall 
> usefulness of fpassthru().  IMO, $length should be added for language-level 
> completeness/convenience but it might also be a good idea to mention 
> X-Sendfile/X-Accel-Redirect in the documentation for fpassthru() so that 
> users are encouraged to leverage resource-efficient technologies wherever 
> possible.
> 

I agree it's a good idea to add this to the manual, although it should be noted 
that not every place where PHP is provided for hosting has this functionality 
available.

> 
>> Ended up with a
>> $output = fopen('php://output', 'wb'); + stream_copy_to_stream()
>> hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
>> the way)
>>
>>
>> On Sat, Feb 11, 2023, 15:26 Niels Dossche  wrote:
>>
>>> Dear internals
>>>
>>> I would like to gain RFC karma for creating and proposing an RFC:
>>> "Implement GH-9673: $length argument for fpassthru".
>>> Account name: nielsdos
>>>
>>> Thanks in advance
>>> Kind regards
>>> Niels
> 
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC karma request

[Hans Henrik Bergan]

Good point, and come to think of it, people wishing to $offset can fseek()
before before fpassthru() anyway. Nevermind the $offset thing, it's more
trouble than it's worth ^^

On Sun, Feb 12, 2023, 15:46 Thomas Hruska  wrote:

> On 2/12/2023 5:47 AM, Hans Henrik Bergan wrote:
> > Fwiw I would also find an $offset argument useful. fpassthru's lack of
> both
> > $length and $offset made my life harder when implementing "HTTP 206
> Partial
> > Content" / "HTTP range requests",
>
> I was going to suggest this myself until I realized that an $offset
> parameter would be rather problematic.  What happens if the offset is
> negative?  Does a negative offset mean seek backwards from the current
> position OR start at that many bytes from the end of the stream?  Is the
> offset a seek operation or a read operation?  Not all streams are
> seekable and reading is generally a fairly slow, blocking I/O operation.
>   Also, not all stream lengths are known.  A negative offset in
> non-seekable scenarios would almost certainly have to throw an error.
> fseek()/fread() are more flexible and consistent for getting to the
> desired starting point in a source stream.
>
> A negative $length would also present some issues.  Again, not all
> stream lengths are known.  Correctly handling negative values would
> require managing an internally, temporarily allocated buffer of
> sufficient size to be able to backtrack streams of unknown length.  And
> might even have to cache the entire stream in RAM, which would be
> problematic for 1GB+ streams.  Or just throw an error for such streams.
> Or just restrict $length to non-negative values only.
>
> In short, a non-negative, nullable $length parameter is the only
> well-defined operation for fpassthru().
>
> fpassthru() is largely a convenience wrapper around fread()/unbuffered
> echo in a loop with some extra output buffer management and is subject
> to PHP max_execution_time.  For large files and/or slow/high latency
> networks, PHP can timeout before delivering all content.
>
> There are several web server extensions available (X-Sendfile and
> X-Accel-Redirect) where, for local files, the rest of the request can be
> handed off from PHP to the web server to completely avoid writing any
> file output to the output buffer and also avoid timeout issues.  The
> existence of modern web server extensions for all major web servers
> limits the overall usefulness of fpassthru().  IMO, $length should be
> added for language-level completeness/convenience but it might also be a
> good idea to mention X-Sendfile/X-Accel-Redirect in the documentation
> for fpassthru() so that users are encouraged to leverage
> resource-efficient technologies wherever possible.
>
>
> > Ended up with a
> > $output = fopen('php://output', 'wb'); + stream_copy_to_stream()
> > hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
> > the way)
> >
> >
> > On Sat, Feb 11, 2023, 15:26 Niels Dossche 
> wrote:
> >
> >> Dear internals
> >>
> >> I would like to gain RFC karma for creating and proposing an RFC:
> >> "Implement GH-9673: $length argument for fpassthru".
> >> Account name: nielsdos
> >>
> >> Thanks in advance
> >> Kind regards
> >> Niels
>
>
> --
> Thomas Hruska
> CubicleSoft President
>
> CubicleSoft has over 80 original open source projects and counting.
> Plus a couple of commercial/retail products.
>
> What software are you looking to build?
>
>

Re: [PHP-DEV] RFC karma request

[Thomas Hruska]

On 2/12/2023 5:47 AM, Hans Henrik Bergan wrote:

Fwiw I would also find an $offset argument useful. fpassthru's lack of both
$length and $offset made my life harder when implementing "HTTP 206 Partial
Content" / "HTTP range requests",


I was going to suggest this myself until I realized that an $offset 
parameter would be rather problematic.  What happens if the offset is 
negative?  Does a negative offset mean seek backwards from the current 
position OR start at that many bytes from the end of the stream?  Is the 
offset a seek operation or a read operation?  Not all streams are 
seekable and reading is generally a fairly slow, blocking I/O operation. 
 Also, not all stream lengths are known.  A negative offset in 
non-seekable scenarios would almost certainly have to throw an error. 
fseek()/fread() are more flexible and consistent for getting to the 
desired starting point in a source stream.


A negative $length would also present some issues.  Again, not all 
stream lengths are known.  Correctly handling negative values would 
require managing an internally, temporarily allocated buffer of 
sufficient size to be able to backtrack streams of unknown length.  And 
might even have to cache the entire stream in RAM, which would be 
problematic for 1GB+ streams.  Or just throw an error for such streams. 
Or just restrict $length to non-negative values only.


In short, a non-negative, nullable $length parameter is the only 
well-defined operation for fpassthru().


fpassthru() is largely a convenience wrapper around fread()/unbuffered 
echo in a loop with some extra output buffer management and is subject 
to PHP max_execution_time.  For large files and/or slow/high latency 
networks, PHP can timeout before delivering all content.


There are several web server extensions available (X-Sendfile and 
X-Accel-Redirect) where, for local files, the rest of the request can be 
handed off from PHP to the web server to completely avoid writing any 
file output to the output buffer and also avoid timeout issues.  The 
existence of modern web server extensions for all major web servers 
limits the overall usefulness of fpassthru().  IMO, $length should be 
added for language-level completeness/convenience but it might also be a 
good idea to mention X-Sendfile/X-Accel-Redirect in the documentation 
for fpassthru() so that users are encouraged to leverage 
resource-efficient technologies wherever possible.




Ended up with a
$output = fopen('php://output', 'wb'); + stream_copy_to_stream()
hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
the way)


On Sat, Feb 11, 2023, 15:26 Niels Dossche  wrote:


Dear internals

I would like to gain RFC karma for creating and proposing an RFC:
"Implement GH-9673: $length argument for fpassthru".
Account name: nielsdos

Thanks in advance
Kind regards
Niels



--
Thomas Hruska
CubicleSoft President

CubicleSoft has over 80 original open source projects and counting.
Plus a couple of commercial/retail products.

What software are you looking to build?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC karma request

[Niels Dossche]

On 12/02/2023 13:47, Hans Henrik Bergan wrote:
> Fwiw I would also find an $offset argument useful. fpassthru's lack of both
> $length and $offset made my life harder when implementing "HTTP 206 Partial
> Content" / "HTTP range requests",
> 
> Ended up with a
> $output = fopen('php://output', 'wb'); + stream_copy_to_stream()
> hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
> the way)
> 
> 
> On Sat, Feb 11, 2023, 15:26 Niels Dossche  wrote:
> 
>> Dear internals
>>
>>
>> I would like to gain RFC karma for creating and proposing an RFC:
>> "Implement GH-9673: $length argument for fpassthru".
>> Account name: nielsdos
>>
>>
>> Thanks in advance
>> Kind regards
>> Niels
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>>
> 

I agree, it's also even more consistent with the other PHP functions, which I 
like.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC karma request

[Hans Henrik Bergan]

Fwiw I would also find an $offset argument useful. fpassthru's lack of both
$length and $offset made my life harder when implementing "HTTP 206 Partial
Content" / "HTTP range requests",

Ended up with a
$output = fopen('php://output', 'wb'); + stream_copy_to_stream()
hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
the way)


On Sat, Feb 11, 2023, 15:26 Niels Dossche  wrote:

> Dear internals
>
>
> I would like to gain RFC karma for creating and proposing an RFC:
> "Implement GH-9673: $length argument for fpassthru".
> Account name: nielsdos
>
>
> Thanks in advance
> Kind regards
> Niels
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] RFC karma request

[Niels Dossche]

Dear internals


I would like to gain RFC karma for creating and proposing an RFC: "Implement 
GH-9673: $length argument for fpassthru".
Account name: nielsdos


Thanks in advance
Kind regards
Niels

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC karma request

[juan carlos morales]

I kindly ask to get RFC Karma, I already have wiki account.

RFC: is_json() function

I have previously write an email to Internals regarding this feature I
would like to include, and feedback was positive (email subject RFC Idea -
is_json - looking for feedback).

Thanks in advance.

Juan

[PHP-DEV] RFC karma request

[Aaron Junker]

Hi all,

I would like to request karma to create a RFC for a global php.net login 
system. The RFC will show up different scenarios and aspects, on which you will 
be able to vote on, so that it gets easier to get an overview what the PHP 
developer want.

Wiki username: aaron-junker

Best regards
Aaron Junker

[PHP-DEV] RFC karma Request

[Saif Eddin Gmati]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Internals,

I'm requesting karma to open an RFC for sealed classes feature.

wiki username: azjezz
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFzBAEBCAAGBQJggxwSACEJELAOCkaz8cFXFiEEOazMpP0wDQTIQG6zsA4K
RrPxwVdBzBAAg7C5m8vqTasy5vnYE3bzblopTOaCmCFWNr1XK0mHTUT/gpBL
hUtkMFeoy5ZvhXv4iRoZOsfi+nucuPl97ikFwuGYF7AQcBkER5+ge2ZmOX4n
xHqtTqhl+u81/DMPynIzKogRQTA+CEPeocM8IS63OCOnijgQWX2jKQSJtWlQ
HpFCVYxamvY1mppTi/kEHO8gGRG96PvufffHaP5A+u3lkdNtJ6BAc8Nbst2S
j8ne1DJ1AI5HlGEXcnkgMlIV2ksjkFGL1v9T6g9flCyPK1zUXR5HsLbhvSGb
Pco1INa76RxKPMKBP7pIa38+AACWn8cOfmzIjsAG4sHI/oCebrpmTUY3QGtl
CRgxKrvO12X27YHjlwtgViu6lXHcTIitho48Y4kh6sU0zCNjZMX5Y+XeSA2b
HmKhs7SCCvQiYnzQXub1cY4f2nFNaVGZPXgQ4hvnHpFhG0n0w+Vcs1U4w8vw
VxA03LDTa+xmEg+qwc5EYHJjYl8UtTMveIAiR1FHKGLAxVXgXVb4dUeWk3Cj
8/V8LCZJY1ou/73/uTy5Tc/uPU8SlZuiDJRZUu61SjwOfOs8SIbddlYPt2nP
ACdG84/hYmxdN7n9o8yfpWHzRV4ntJ4Ls+XzeexQ1Z2vw4VW2raTq7NZu2yL
jMK6nR4uPaQjFwFZZxv/2PkJsRoy8QLIKrY=
=NU5a
-END PGP SIGNATURE-

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC karma request

[Pavel Patapau]

Hello internals,

Please, provide RFC karma for creating proposal "Guard statement" 
https://github.com/php/php-src/pull/5578.


account: alherd


--
Pavel Patapau

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC karma request

[Benas IML]

Hey internals,

I need RFC karma for creating and proposing the "Renaming PhpAttribute" RFC.
Account's username: moliata

Best regards,
Benas Seliuginas.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC karma request

[Max Semenik]

Hi, can I get RFC karma please? I'd like to write a RFC related to
https://github.com/php/php-src/pull/5345

My account name is maxsem.

-- 
Best regards,
Max Semenik

Re: [PHP-DEV] RFC Karma Request

[Christoph Becker]

On 27.07.2016 at 13:53, Michał Brzuchalski:

> 2016-07-27 12:24 GMT+02:00 Christoph Becker :
> 
>> However, that still would require something like
>>
>>   $str[0..mb_strlen($needle)-1] == $needle
> 
> I've been working on range operator some time ago and had problem with
> double-dot ".." as an operator because of conflict with concat operator.
> 0..5 could be 0. . 5, or 0 . .5 white spaces are problem here,
> unfortunately dot is concat operator and decimal separator.

Well, there's a similar issue with `- -$n` vs. `--$n` anyway, but of
course we could use something else than `..` (`:` comes to mind; not
sure if that would work).

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Karma Request

[Michał Brzuchalski]

2016-07-27 12:24 GMT+02:00 Christoph Becker :

> On 27.07.2016 at 02:55, Davey Shafik wrote:
>
> > Ah, I missed that. If we had ranges (e.g. $string[0..4] or
> $string[-1..4])
> > that'd work, but we don't.
>
> However, that still would require something like
>
>   $str[0..mb_strlen($needle)-1] == $needle
>

I've been working on range operator some time ago and had problem with
double-dot ".." as an operator because of conflict with concat operator.
0..5 could be 0. . 5, or 0 . .5 white spaces are problem here,
unfortunately dot is concat operator and decimal separator.


>
> > Now I see some value in the function, though still perhaps not enough to
> > justify above and beyond strpos etc.
>
> One advantage of the new functions over userland implementations would
> be efficiency.  A strpos() would still require to search the whole
> string if the $needle is not found.  substr() and string slices would
> require a copy unless that would be optimized, if a general optimization
> is possible at all.
>
> Not sure, if I like to see yet two more string functions in the global
> namespace, though.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
pozdrawiam
--
Michał Brzuchalski

Re: [PHP-DEV] RFC Karma Request

[Christoph Becker]

On 27.07.2016 at 02:55, Davey Shafik wrote:

> Ah, I missed that. If we had ranges (e.g. $string[0..4] or $string[-1..4])
> that'd work, but we don't.

However, that still would require something like

  $str[0..mb_strlen($needle)-1] == $needle

> Now I see some value in the function, though still perhaps not enough to
> justify above and beyond strpos etc.

One advantage of the new functions over userland implementations would
be efficiency.  A strpos() would still require to search the whole
string if the $needle is not found.  substr() and string slices would
require a copy unless that would be optimized, if a general optimization
is possible at all.

Not sure, if I like to see yet two more string functions in the global
namespace, though.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Karma Request

[Ferenc Kovacs]

On Tue, Jul 26, 2016 at 8:41 PM,  wrote:

> Hello,
>
> I would like to submit an RFC for adding a str_begins and str_ends
> function, in relation to https://bugs.php.net/bug.php?id=67035 and
> https://bugs.php.net/bug.php?id=50434. I've added those functions on my
> local PHP copy. I would like to make an RFC and a PR for adding it to the
> core PHP copy.
>
> Thanks,
>
> Will
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
hi,

I've just granted you rfc karma on the wiki.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] RFC Karma Request

[Davey Shafik]

Ah, I missed that. If we had ranges (e.g. $string[0..4] or $string[-1..4])
that'd work, but we don't.

Now I see some value in the function, though still perhaps not enough to
justify above and beyond strpos etc.


On Tue, Jul 26, 2016 at 5:11 PM,  wrote:

> Davey,
>
> Thanks for joining the conversation! That code snippet is very elegant,
> and it is a superb way of checking if a string starts with or ends with a
> specific character. However, it does not check if a string starts with or
> ends with a specific string, containing multiple characters.
>
> True str_begins and str_ends would do check if a string begins or ends
> with a string of n characters.
>
> Regards,
>
> -Will
>
>
> On 2016-07-26 19:39, Davey Shafik wrote:
>
>> Will,
>>
>> Now that we have generalized support for negative string offsets you
>> can now just do:
>>
>> $string = "/foo/bar/bat/";
>> if ($string[0] === "/") { // fully-qualified path }
>> if ($string[-1] === "/") { // trailing "/" }
>>
>> This avoids the overhead of a function call, arguably is as
>> expressive, and a lot more functional (e.g. offset -2).
>>
>> - Davey
>>
>> On Tue, Jul 26, 2016 at 2:27 PM,  wrote:
>>
>> Thanks for replying David.
>>>
>>> Thanks for the questions, its good to elaborate on things some. I'll
>>> address each question here:
>>>
>>> 1. No, I guess this is my first time reaching out to the community.
>>> I had gone with str_begins and str_ends because it fit some of the
>>> current naming approaches. I could see an argument for
>>> strstarts/strends, strbegins/strends, or startsWith/endsWith. I'm
>>> flexible with the exact naming.
>>>
>>> 2. I don't think performance-wise it would be a big improvement over
>>> using strpos, preg_match, or substr. However, I think it might be an
>>> improvement readability-wise. Right now people either use somewhat
>>> confusing code, like strpos or substr, or they implement their own
>>> user-defined str_starts function. I think the benefit in terms of
>>> readability and usability justifies the addition of two new
>>> functions to the namespace.
>>>
>>> 3. This functionality is doable with the current implementation.
>>> However, part of the goal of languages or tools is to make it easy
>>> to do common, routine tasks. Python, Java, Ruby, C# and JavaScript
>>> all provide this functionality. So I am sure people would find it
>>> useful in PHP.
>>>
>>> 4. Right now, the way I have it implemented, it is case-sensitive.
>>> If people wanted, it could be implemented to take an optional
>>> boolean parameter called case_sensitive which defaults to true. I
>>> could make that change pretty easily, if I did that the function
>>> headers would be:
>>>
>>> boolean str_starts (string $str , str $search_value [, bool
>>> $case_sensitive = true ] )
>>> boolean str_ends (string $str , str $search_value [, bool
>>> $case_sensitive = true ] )
>>>
>>> I like the idea of doing that instead of having separate,
>>> case-insensitive, functions because it helps keep the name space
>>> less cluttered.
>>>
>>> I hope this has provided some helpful information. Please get back
>>> with me with your thoughts.
>>>
>>> Thanks,
>>> Will
>>>
>>> On 2016-07-26 16:09, David Rodrigues wrote:
>>> Questions:
>>>
>>> 1.
>>> Have you talked with this list about the terms of you suggestions?
>>> (like str_begins, str_starts, strstarts, strbegins, str_ends,
>>> strends...)
>>> Is yes, sorry, I do not received this topic before.
>>>
>>> 2.
>>> There some valid performance advantage over strpos()?
>>>
>>> 3.
>>> And about the "market" for this new function?
>>> I mean, about users really need a new function like it on core.
>>>
>>> 4.
>>> And about the case sensitiblity?
>>> Should have some function like stribegins() or will be an argument?
>>>
>>> In general, I like this implementation, but I like to know about you
>>> in this questions.
>>> I don't know the policy about implements new functions on "str
>>> namespace".
>>>
>>> Thanks!
>>>
>>> 2016-07-26 15:41 GMT-03:00  :
>>> Hello,
>>>
>>> I would like to submit an RFC for adding a str_begins and str_ends
>>> function,
>>> in relation to https://bugs.php.net/bug.php?id=67035 and
>>> https://bugs.php.net/bug.php?id=50434. I've added those functions on
>>> my
>>> local PHP copy. I would like to make an RFC and a PR for adding it
>>> to the
>>> core PHP copy.
>>>
>>> Thanks,
>>>
>>> Will
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>

Re: [PHP-DEV] RFC Karma Request

[will]

Davey,

Thanks for joining the conversation! That code snippet is very elegant, 
and it is a superb way of checking if a string starts with or ends with 
a specific character. However, it does not check if a string starts with 
or ends with a specific string, containing multiple characters.


True str_begins and str_ends would do check if a string begins or ends 
with a string of n characters.


Regards,

-Will

On 2016-07-26 19:39, Davey Shafik wrote:

Will,

Now that we have generalized support for negative string offsets you
can now just do:

$string = "/foo/bar/bat/";
if ($string[0] === "/") { // fully-qualified path }
if ($string[-1] === "/") { // trailing "/" }

This avoids the overhead of a function call, arguably is as
expressive, and a lot more functional (e.g. offset -2).

- Davey

On Tue, Jul 26, 2016 at 2:27 PM,  wrote:


Thanks for replying David.

Thanks for the questions, its good to elaborate on things some. I'll
address each question here:

1. No, I guess this is my first time reaching out to the community.
I had gone with str_begins and str_ends because it fit some of the
current naming approaches. I could see an argument for
strstarts/strends, strbegins/strends, or startsWith/endsWith. I'm
flexible with the exact naming.

2. I don't think performance-wise it would be a big improvement over
using strpos, preg_match, or substr. However, I think it might be an
improvement readability-wise. Right now people either use somewhat
confusing code, like strpos or substr, or they implement their own
user-defined str_starts function. I think the benefit in terms of
readability and usability justifies the addition of two new
functions to the namespace.

3. This functionality is doable with the current implementation.
However, part of the goal of languages or tools is to make it easy
to do common, routine tasks. Python, Java, Ruby, C# and JavaScript
all provide this functionality. So I am sure people would find it
useful in PHP.

4. Right now, the way I have it implemented, it is case-sensitive.
If people wanted, it could be implemented to take an optional
boolean parameter called case_sensitive which defaults to true. I
could make that change pretty easily, if I did that the function
headers would be:

boolean str_starts (string $str , str $search_value [, bool
$case_sensitive = true ] )
boolean str_ends (string $str , str $search_value [, bool
$case_sensitive = true ] )

I like the idea of doing that instead of having separate,
case-insensitive, functions because it helps keep the name space
less cluttered.

I hope this has provided some helpful information. Please get back
with me with your thoughts.

Thanks,
Will

On 2016-07-26 16:09, David Rodrigues wrote:
Questions:

1.
Have you talked with this list about the terms of you suggestions?
(like str_begins, str_starts, strstarts, strbegins, str_ends,
strends...)
Is yes, sorry, I do not received this topic before.

2.
There some valid performance advantage over strpos()?

3.
And about the "market" for this new function?
I mean, about users really need a new function like it on core.

4.
And about the case sensitiblity?
Should have some function like stribegins() or will be an argument?

In general, I like this implementation, but I like to know about you
in this questions.
I don't know the policy about implements new functions on "str
namespace".

Thanks!

2016-07-26 15:41 GMT-03:00  :
Hello,

I would like to submit an RFC for adding a str_begins and str_ends
function,
in relation to https://bugs.php.net/bug.php?id=67035 and
https://bugs.php.net/bug.php?id=50434. I've added those functions on
my
local PHP copy. I would like to make an RFC and a PR for adding it
to the
core PHP copy.

Thanks,

Will

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Karma Request

[Davey Shafik]

Will,

Now that we have generalized support for negative string offsets you can
now just do:

$string = "/foo/bar/bat/";
if ($string[0] === "/") { // fully-qualified path }
if ($string[-1] === "/") { // trailing "/" }

This avoids the overhead of a function call, arguably is as expressive, and
a lot more functional (e.g. offset -2).

- Davey

On Tue, Jul 26, 2016 at 2:27 PM,  wrote:

> Thanks for replying David.
>
> Thanks for the questions, its good to elaborate on things some. I'll
> address each question here:
>
> 1. No, I guess this is my first time reaching out to the community. I had
> gone with str_begins and str_ends because it fit some of the current naming
> approaches. I could see an argument for strstarts/strends,
> strbegins/strends, or startsWith/endsWith. I'm flexible with the exact
> naming.
>
> 2. I don't think performance-wise it would be a big improvement over using
> strpos, preg_match, or substr. However, I think it might be an improvement
> readability-wise. Right now people either use somewhat confusing code, like
> strpos or substr, or they implement their own user-defined str_starts
> function. I think the benefit in terms of readability and usability
> justifies the addition of two new functions to the namespace.
>
> 3. This functionality is doable with the current implementation. However,
> part of the goal of languages or tools is to make it easy to do common,
> routine tasks. Python, Java, Ruby, C# and JavaScript all provide this
> functionality. So I am sure people would find it useful in PHP.
>
> 4. Right now, the way I have it implemented, it is case-sensitive. If
> people wanted, it could be implemented to take an optional boolean
> parameter called case_sensitive which defaults to true. I could make that
> change pretty easily, if I did that the function headers would be:
>
> boolean str_starts (string $str , str $search_value [, bool
> $case_sensitive = true ] )
> boolean str_ends (string $str , str $search_value [, bool $case_sensitive
> = true ] )
>
> I like the idea of doing that instead of having separate,
> case-insensitive, functions because it helps keep the name space less
> cluttered.
>
> I hope this has provided some helpful information. Please get back with me
> with your thoughts.
>
> Thanks,
> Will
>
>
> On 2016-07-26 16:09, David Rodrigues wrote:
>
>> Questions:
>>
>> 1.
>> Have you talked with this list about the terms of you suggestions?
>> (like str_begins, str_starts, strstarts, strbegins, str_ends,
>> strends...)
>> Is yes, sorry, I do not received this topic before.
>>
>> 2.
>> There some valid performance advantage over strpos()?
>>
>> 3.
>> And about the "market" for this new function?
>> I mean, about users really need a new function like it on core.
>>
>> 4.
>> And about the case sensitiblity?
>> Should have some function like stribegins() or will be an argument?
>>
>> In general, I like this implementation, but I like to know about you
>> in this questions.
>> I don't know the policy about implements new functions on "str namespace".
>>
>> Thanks!
>>
>> 2016-07-26 15:41 GMT-03:00  :
>>
>>> Hello,
>>>
>>> I would like to submit an RFC for adding a str_begins and str_ends
>>> function,
>>> in relation to https://bugs.php.net/bug.php?id=67035 and
>>> https://bugs.php.net/bug.php?id=50434. I've added those functions on my
>>> local PHP copy. I would like to make an RFC and a PR for adding it to the
>>> core PHP copy.
>>>
>>> Thanks,
>>>
>>> Will
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] RFC Karma Request

[will]

Thanks for replying David.

Thanks for the questions, its good to elaborate on things some. I'll 
address each question here:


1. No, I guess this is my first time reaching out to the community. I 
had gone with str_begins and str_ends because it fit some of the current 
naming approaches. I could see an argument for strstarts/strends, 
strbegins/strends, or startsWith/endsWith. I'm flexible with the exact 
naming.


2. I don't think performance-wise it would be a big improvement over 
using strpos, preg_match, or substr. However, I think it might be an 
improvement readability-wise. Right now people either use somewhat 
confusing code, like strpos or substr, or they implement their own 
user-defined str_starts function. I think the benefit in terms of 
readability and usability justifies the addition of two new functions to 
the namespace.


3. This functionality is doable with the current implementation. 
However, part of the goal of languages or tools is to make it easy to do 
common, routine tasks. Python, Java, Ruby, C# and JavaScript all provide 
this functionality. So I am sure people would find it useful in PHP.


4. Right now, the way I have it implemented, it is case-sensitive. If 
people wanted, it could be implemented to take an optional boolean 
parameter called case_sensitive which defaults to true. I could make 
that change pretty easily, if I did that the function headers would be:


boolean str_starts (string $str , str $search_value [, bool 
$case_sensitive = true ] )
boolean str_ends (string $str , str $search_value [, bool 
$case_sensitive = true ] )


I like the idea of doing that instead of having separate, 
case-insensitive, functions because it helps keep the name space less 
cluttered.


I hope this has provided some helpful information. Please get back with 
me with your thoughts.


Thanks,
Will

On 2016-07-26 16:09, David Rodrigues wrote:

Questions:

1.
Have you talked with this list about the terms of you suggestions?
(like str_begins, str_starts, strstarts, strbegins, str_ends,
strends...)
Is yes, sorry, I do not received this topic before.

2.
There some valid performance advantage over strpos()?

3.
And about the "market" for this new function?
I mean, about users really need a new function like it on core.

4.
And about the case sensitiblity?
Should have some function like stribegins() or will be an argument?

In general, I like this implementation, but I like to know about you
in this questions.
I don't know the policy about implements new functions on "str 
namespace".


Thanks!

2016-07-26 15:41 GMT-03:00  :

Hello,

I would like to submit an RFC for adding a str_begins and str_ends 
function,

in relation to https://bugs.php.net/bug.php?id=67035 and
https://bugs.php.net/bug.php?id=50434. I've added those functions on 
my
local PHP copy. I would like to make an RFC and a PR for adding it to 
the

core PHP copy.

Thanks,

Will

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Karma Request

[David Rodrigues]

Questions:

1.
Have you talked with this list about the terms of you suggestions?
(like str_begins, str_starts, strstarts, strbegins, str_ends,
strends...)
Is yes, sorry, I do not received this topic before.

2.
There some valid performance advantage over strpos()?

3.
And about the "market" for this new function?
I mean, about users really need a new function like it on core.

4.
And about the case sensitiblity?
Should have some function like stribegins() or will be an argument?

In general, I like this implementation, but I like to know about you
in this questions.
I don't know the policy about implements new functions on "str namespace".

Thanks!

2016-07-26 15:41 GMT-03:00  :
> Hello,
>
> I would like to submit an RFC for adding a str_begins and str_ends function,
> in relation to https://bugs.php.net/bug.php?id=67035 and
> https://bugs.php.net/bug.php?id=50434. I've added those functions on my
> local PHP copy. I would like to make an RFC and a PR for adding it to the
> core PHP copy.
>
> Thanks,
>
> Will
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
David Rodrigues

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC Karma Request

[will]

Hello,

I would like to submit an RFC for adding a str_begins and str_ends 
function, in relation to https://bugs.php.net/bug.php?id=67035 and 
https://bugs.php.net/bug.php?id=50434. I've added those functions on my 
local PHP copy. I would like to make an RFC and a PR for adding it to 
the core PHP copy.


Thanks,

Will

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC karma request re RFC proposal for alternative list syntax

[Ferenc Kovacs]

On Fri, Jan 15, 2016 at 4:45 PM, Julian Rhind 
wrote:

> Hi
>
>
> Thanks all for the feedback - I'm posting back to get some "RFC karma" for
> my newly created wiki account please - so I can post my RFC - username is
> "julian"
>
>
> Thanks
>
>
> Regards
>
>
> Julian
>
>
>
hi Julian,

I've just granted you rfc wiki karma, so you should be able to create/edit
pages under the rfc namespace in the wiki.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] RFC karma request re RFC proposal for alternative list syntax

[Julian Rhind]

Hi


Thanks all for the feedback - I'm posting back to get some "RFC karma" for my 
newly created wiki account please - so I can post my RFC - username is "julian"


Thanks


Regards


Julian



From: Kris Craig 
Sent: 28 December 2015 18:40
To: Pierre Joye
Cc: PHP internals list; Julian Rhind; Stanislav Malyshev
Subject: Re: [PHP-DEV] RFC proposal for alternative list syntax


On Dec 27, 2015 7:56 PM, "Pierre Joye" 
> wrote:
>
> On Mon, Dec 28, 2015 at 6:20 AM, Stanislav Malyshev 
> > wrote:
> > Hi!
> >
> >> // With the new array syntax this has been improved to
> >>
> >> list ($a, $b) = [1, 2];
> >>
> >> // I think this new syntax should logically extend to
> >>
> >> [$a, $b] = [1, 2];
> >
> > list() and array() are two different language constructs, using the same
> > syntax for them is a bad idea.
>
> I tend to agree here but it exists elsewhere and is quite handy. Also
> the behavior of this expression, in this case, is obvious.
>
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

This could be very nice shortcut to have.  Seems intuitive enough; I doubt 
there'd be any serious confusion over this.

You should draft an RFC for this, OP.

--Kris

Re: [PHP-DEV] RFC karma request

[Hannes Magnusson]

On Wed, Jul 18, 2012 at 11:43 PM, Galen Wright-Watson
ww.ga...@gmail.com wrote:
 I'd like to see some version of the null-coalescing ternary operator
 (recently brought up in a thread started by Rafael Dohms) make it into PHP.
 To help it along, may I have RFC karma so I can draft a proposal? My PHP
 wiki account name is outis, e-mail is ww.ga...@gmail.com.

 If there's a better/approved way of getting RFC karma than posting on the
 internals list, please let me know. So far, I haven't been able to find any
 official documentation on how.

The trick is to read the registration page :]

You should now have karma to edit/create stuff in the /rfc namespace.

-Hannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC karma request

[Galen Wright-Watson]

I'd like to see some version of the null-coalescing ternary operator
(recently brought up in a thread started by Rafael Dohms) make it into PHP.
To help it along, may I have RFC karma so I can draft a proposal? My PHP
wiki account name is outis, e-mail is ww.ga...@gmail.com.

If there's a better/approved way of getting RFC karma than posting on the
internals list, please let me know. So far, I haven't been able to find any
official documentation on how.