On 6-4-2024 14:55, Tim Düsterhus wrote:
Hi
On 4/5/24 23:32, Juliette Reinders Folmer wrote:
I also took the liberty to ask accessibility expert Nicolas Steenhout
[1] for his opinion on this topic and he has given me permission to
quote his reply:
> From a human readability and an accessibili
On Sat, Apr 6, 2024 at 4:07 AM Barney Laurance
wrote:
> Hello,
>
> There are currently two proposals being discussed - *native decimal
> scalar type support* and *Support object type in BCMath*
>
> I've been getting involved in the discussion for the BCMath proposal, but
> not paying as much atte
On Sat, Apr 6, 2024 at 6:45 AM Rowan Tommins [IMSoP]
wrote:
> On 06/04/2024 07:24, Saki Takamachi wrote:
>
> Take a look at the methods shown below:
> ```
> protected static function resultPropertyRules(string $propertyName,
> mixed $value1, mixed $value2): mixed {}
> ```
>
> This method determin
Hi Rowan
On Fri, Apr 5, 2024 at 12:28 AM Rowan Tommins [IMSoP]
wrote:
>
> On 03/04/2024 00:01, Ilija Tovilo wrote:
>
> Regardless of the implementation, there are a lot of interactions we will
> want to consider; and we will have to keep considering new ones as we add to
> the language. For ins
Hi Tim,
> Hi
>
> On 4/6/24 17:54, Saki Takamachi wrote:
>> However, in the example from "RFC: Namespaces in bundled PHP extensions",
>> the acronyms are not camelcased. e.g. `FFI\FFI`, `OpenSSL`
>> In other words, the RFC can be interpreted as "excluding acronyms"
>> implicitly.
>
> This is c
Hi
On 4/6/24 17:54, Saki Takamachi wrote:
However, in the example from "RFC: Namespaces in bundled PHP extensions", the
acronyms are not camelcased. e.g. `FFI\FFI`, `OpenSSL`
In other words, the RFC can be interpreted as "excluding acronyms" implicitly.
This is correct, because the current cl
Hi Tim,
>> Strictly speaking, namespace is neither a class nor a method, so isn't it
>> outside the scope of this RFC? In fact, RFC: Class Naming makes no mention
>> of namespace naming conventions at all. I asked this because there was
>> mention of namespaces in the `DOM`.
>> If I'm not misun
Hi
On 4/6/24 17:16, Saki Takamachi wrote:
Strictly speaking, namespace is neither a class nor a method, so isn't it
outside the scope of this RFC? In fact, RFC: Class Naming makes no mention of
namespace naming conventions at all. I asked this because there was mention of
namespaces in the `D
Hi Tim,
> I've just written up the follow-up RFC to my previous “Casing of acronyms in
> class and method names” thread and I'm officially opening up the discussion
> period for it.
>
> Please find the following links for your convenience:
>
> RFC: https://wiki.php.net/rfc/class-naming-acronym
Hi Rowan and folks,
> While this is an intriguing idea, it only solves a narrow set of use cases.
> For instance:
> - The class might want different behaviour for different operations; e.g.
> Money(42, 'USD') + Money(42, 'USD') should give Money(84, 'USD'); but
> Money(42, 'USD') * Money(42, 'U
On 06/04/2024 07:24, Saki Takamachi wrote:
Take a look at the methods shown below:
```
protected static function resultPropertyRules(string $propertyName,
mixed $value1, mixed $value2): mixed {}
```
This method determines which operand value to use in the result after
calculation for a property
Hi
On 4/5/24 22:04, Jordan LeDoux wrote:
That is an absurd example. Why would anyone use inheritance for that class
design? If what you are arguing is "if you look at use cases where
composition is clearly the correct choice then inheritance causes
problems", then I'm not sure what the point of
Hi Barney,
> There are currently two proposals being discussed - native decimal scalar
> type support and Support object type in BCMath
>
> I've been getting involved in the discussion for the BCMath proposal, but not
> paying as much attention to the native decimal thread.
>
> But these seem l
Hi
On 4/5/24 23:32, Juliette Reinders Folmer wrote:
I also took the liberty to ask accessibility expert Nicolas Steenhout
[1] for his opinion on this topic and he has given me permission to
quote his reply:
> From a human readability and an accessibility perspective, Camel Case
are best when
Hello,
There are currently two proposals being discussed - /native decimal
scalar type support/ and /Support object type in BCMath/
I've been getting involved in the discussion for the BCMath proposal,
but not paying as much attention to the native decimal thread.
But these seem like very s
On 5 April 2024 19:30:24 BST, Jordan LeDoux wrote:
>A composed class
>does not somehow prevent the accidental error of mixing currencies, it just
>moves where that error would occur
It does not prevent someone accidentally *attempting* to mix currencies, but it
absolutely prevents that mista
16 matches
Mail list logo
