On Tue, Feb 18, 2025, at 2:00 AM, Rowan Tommins [IMSoP] wrote:
> On 17 February 2025 14:39:42 GMT, Viktor Khramov
> wrote:
>>Hi!
>>
>>The point is here:
>>https://gist.github.com/vhood/665418835e65be26d5a818fded92ab75
>
>
>>Static functions look awful and break the object's API.
>
> Personally, I
On Tue, Feb 18, 2025, at 17:52, Juris Evertovskis wrote:
> Hi,
>
> A recent discussion brought up the need for multiple constructors for the
> same class.
> https://externals.io/message/126428
>
> The need was mostly answered by suggestions to use factory methods.
> However on an earlier dis
Hey,
On Tue, 18 Feb 2025, 13:04 Tim Düsterhus, wrote:
> Hi
>
> Am 2025-02-18 13:46, schrieb Jordi Boggiano:
> >> My question is: Why? Please also have a look at:
> >>
> https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces.
>
> >> Instead of creating a top-level na
Hi
Am 2025-02-18 13:46, schrieb Jordi Boggiano:
My question is: Why? Please also have a look at:
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces.
Instead of creating a top-level namespace for both Brotli and Zstd it
would probably make sense to create a new
On Tue, Feb 18, 2025, at 20:29, Juris Evertovskis wrote:
> On 2025-02-18 19:31, Rob Landers wrote:
>
>>
>>
>> On Tue, Feb 18, 2025, at 17:52, Juris Evertovskis wrote:
>>> Hi,
>>>
>>> A recent discussion brought up the need for multiple constructors for the
>>> same class.
>>> https://extern
Am 18.02.2025, 11:19:26 schrieb Jordi Boggiano :
> Hey,
>
> Kévin Dunglas and myself would like to present this RFC proposing
> inclusion of the zstandard and brotli pecl extensions into core, with
> the main goal of making them more broadly available.
>
> https://wiki.php.net/rfc/modern_compressi
On Tue 18. 2. 2025 at 11:21, Jordi Boggiano wrote:
> Hey,
>
> Kévin Dunglas and myself would like to present this RFC proposing
> inclusion of the zstandard and brotli pecl extensions into core,
It would be really good to get some thoughts of the author of these
extensions (kjdev) because that’
Hi,
A recent discussion brought up the need for multiple constructors for the
same class.
https://externals.io/message/126428
The need was mostly answered by suggestions to use factory methods.
However on an earlier discussion it was discussed how it's fine and even
useful for constructor
Hi
On 2/18/25 18:31, Rob Landers wrote:
You may be interested in a super-draft RFC that I’ll propose in the next few
days…
May I kindly request some breathing room with regard to new RFC
discussions so that folks are able to give each RFC the proper
attention. The list currently is super ac
On 2025-02-18 19:31, Rob Landers wrote:
On Tue, Feb 18, 2025, at 17:52, Juris Evertovskis wrote:
Hi,
A recent discussion brought up the need for multiple constructors for
the same class.
https://externals.io/message/126428
The need was mostly answered by suggestions to use factory methods
On Feb 18, 2025, at 08:43, Kévin Dunglas wrote:Hi there,Here is an alternative proposal we just discussed with Jordi:First, reduce the scope of our RFC to simply add new stream wrappers for Zstandard and Brotli similar to those already provided for zlib: https://www.php.net/manual/en/wrappers.com
On Tue, Feb 18, 2025, at 20:24, Tim Düsterhus wrote:
> Hi
>
> On 2/18/25 18:31, Rob Landers wrote:
> > You may be interested in a super-draft RFC that I’ll propose in the next
> > few days…
>
> May I kindly request some breathing room with regard to new RFC
> discussions so that folks are able
Hi
Am 2025-02-18 11:19, schrieb Jordi Boggiano:
Thanks for your consideration, we're looking forward to hearing your
feedback!
The RFC specifies that:
The zstd implementation includes a few global functions as well as
namespaced ones
My question is: Why? Please also have a look at:
https
Hi
Am 2025-02-18 09:00, schrieb Rowan Tommins [IMSoP]:
Personally, I think quite the opposite: named constructors make a lot
more sense than type-based overloads. For instance, you might have both
createFromJson and createFromYaml; their inputs are both going to be
"string" as far as the type
On Mon, Feb 17, 2025, at 20:31, Edmond Dantes wrote:
> > There should be no perceptible difference between a blocking sleep(10) and
> > an async sleep(10), so what backwards compatibility are you referring to?
>
> For example, the behavior of the code below will not change. The code will
> ex
On 11.02.2025 14:18, Arnaud Le Blanc wrote:
At the moment, there is no direct way to fetch the currently
registered error or exception handlers. Users who need to inspect
these handlers must resort to a workaround that temporarily sets a new
handler and then immediately restores the previous one:
Hi
Am 2025-02-18 14:22, schrieb Paul Dragoonis:
Having spent many years in PHP-FIG and lots of effort trying to build
one
"standard" for lots of implementations that differ. I just want to
point
out that I think we should avoid trying to make a standard design for
all
the Compression drivers a
On Tue, Feb 18, 2025 at 10:27 AM Viktor Khramov
wrote:
> Decision::createFromId($uuid, $comment);
> Decision::createFromMail($subject, $body);
> Decision::createFromSome($a, $b, $c);
> Decision::createFromAnother($a);
>
> This doesn't look like constructors. It will be hard to read the
> class, i
Hey Tim,
On 18.02.2025 12:30, Tim Düsterhus wrote:
My question is: Why? Please also have a look at:
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces.
Instead of creating a top-level namespace for both Brotli and Zstd it
would probably make sense to create a
>
> I think what bilge was trying to point out is that there should be
> absolutely no change on existing software with or without the scheduler
> running (for software not using fibers).
>
I thought the same. But where would you hide Fibers? They are part of the
language.
The existence of Fibers
Hi there,
Here is an alternative proposal we just discussed with Jordi:
First, reduce the scope of our RFC to simply add new stream wrappers for
Zstandard and Brotli similar to those already provided for zlib:
https://www.php.net/manual/en/wrappers.compression.php
PECL extensions for Brotli and
On Tue, 18 Feb 2025 at 12:45, Sebastian Bergmann wrote:
> Am 18.02.2025 um 09:00 schrieb Rowan Tommins [IMSoP]:
> > named constructors make a lot more sense than type-based overloads
>
> +1
>
Hi, Viktor.
I agree with others that named static constructors are much better
than overloading
of the
Hey,
Kévin Dunglas and myself would like to present this RFC proposing
inclusion of the zstandard and brotli pecl extensions into core, with
the main goal of making them more broadly available.
https://wiki.php.net/rfc/modern_compression
Thanks for your consideration, we're looking forward t
> First, reduce the scope of our RFC to simply add new stream wrappers for
> Zstandard and Brotli similar to those already provided for zlib:
> https://www.php.net/manual/en/wrappers.compression.php
> To keep things moving quickly, we won't be adding any new functions or
> classes (perhaps just
Decision::createFromId($uuid, $comment);
Decision::createFromMail($subject, $body);
Decision::createFromSome($a, $b, $c);
Decision::createFromAnother($a);
This doesn't look like constructors. It will be hard to read the
class, it will take time to come up with a name, it's not right. I
have differ
On 17 February 2025 14:39:42 GMT, Viktor Khramov
wrote:
>Hi!
>
>The point is here:
>https://gist.github.com/vhood/665418835e65be26d5a818fded92ab75
>Static functions look awful and break the object's API.
Personally, I think quite the opposite: named constructors make a lot more
sense than
Am 18.02.2025 um 09:00 schrieb Rowan Tommins [IMSoP]:
named constructors make a lot more sense than type-based overloads
+1
27 matches
Mail list logo
