On Wed, Mar 25, 2020 at 6:28 AM Christoph M. Becker wrote:
>
> It seems to me that the RFC is not sufficiently specific enough
> regarding the concatenation of instances of classes which implement
> __toString().
Exactly what I was thinking too. Would be nice with some examples on this.
> So if
Hi Larry and Nicolas,
On Wed, Mar 25, 2020 at 9:24 AM Larry Garfield wrote:
> > I'd like to propose something on the topic.
> > I'm adding object literals to the mix because that's another feature of the
> > language that we're missing a lot IMHO.
> > Actually, there is one existing syntax for
Hi,
Hope everyone is doing alright. I just raised a new RFC
(https://wiki.php.net/rfc/add_str_starts_with_and_ends_with_functions ,
github patch: https://github.com/php/php-src/pull/5300) for adding
str_starts_with and str_ends_with to PHP. I would like to open this RFC
up to discussion.
I
> Le 26 mars 2020 à 01:11, Levi Morrison via internals
> a écrit :
>
> It's bothered me for quite some time that a failed include emits a
> warning. This is because it's by design that the author chose
> `include` and not `require`. It's _expected_ that it may fail and they
> are okay with
Hello!
> What's wrong with new Number(123)?
Actually it is a simplest case, where only a single information was
considered. But you can expand it to something more complex, where
currently you will need create a static method to copy the data, which is
not a normalized way like cast could do.
>
It's bothered me for quite some time that a failed include emits a
warning. This is because it's by design that the author chose
`include` and not `require`. It's _expected_ that it may fail and they
are okay with that.
As an example, consider a classic autoloading case. It could be as
simple and
Hi!
> 1. Converting from A to B:
>
> $a = 123;
> $b = (Number) $a; // $b is now instanceof Number
>
> A instanceof Number will created based on $a value.
What's wrong with new Number(123)?
> 2. Reduce object type (I don't know the technical term):
>
> class A {}
> class B extends A {}
>
>
To me, this is almost a good idea. However, I would want regular type
checking, not casts. Importantly, regular type checks would fit well
on allowing array destructuring directly in function signatures, which
would basically be a form of named parameters.
--
PHP Internals - PHP Runtime
Ilija Tovilo wrote:
Hi Andrea
but I am surprised you haven't mentioned the `and` and `or` operators
I did mention them in the RFC here:
https://wiki.php.net/rfc/throw_expression
If this RFC is accepted they will indeed be possible __
Regards
Oh, you are quite right! Sorry, I must not
Hi Andrea
> I would think we can just give `throw` an appropriate precedence so that
> expressions like the above do what is desired
The example are taken from the RFC online. The following expression is already
possible:
```php
throw $condition1 && $condition2 ? new Exception1() : new
Hi Andrea
> but I am surprised you haven't mentioned the `and` and `or` operators
I did mention them in the RFC here:
https://wiki.php.net/rfc/throw_expression
If this RFC is accepted they will indeed be possible __
Regards
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi Dan,
Dan Ackroyd wrote:
Regarding the example:
$condition || throw new Exception('$condition must be truthy')
&& $condition2 || throw new Exception('$condition2 must be truthy');
The "Deprecate left-associative ternary operator"* RFC made it so that
parentheses are required when ternary
Hey Ilija,
Ilija Tovilo wrote:
Hi everybody! I hope you’re doing well.
Due to the modest feedback I’d like to move the throw expression RFC to “under
discussion”.
https://wiki.php.net/rfc/throw_expression
In short, the RFC proposes to convert the throw statement into an expression
Hi, Enno,
En mié, 25 mar 2020 18:53:15 +0100 Enno Woortmann
escribió
> Hi,
>
> I've written the RFC and implemented a first patch concerning the idea
> to allow type casting in array destructuring expressions.
>
>
> The RFC is located at
Hi, internals,
En mié, 25 mar 2020 17:21:29 +0100 Rowan Tommins
escribió
> On Wed, 25 Mar 2020 at 15:29, Ilija Tovilo wrote:
>
> > I don't think this would add any significant benefit over:
> >
> > ```php
> > $x = true switch {
> > $x !== null && $x < 5 => ...
> > }
Hi,
I've written the RFC and implemented a first patch concerning the idea
to allow type casting in array destructuring expressions.
The RFC is located at https://wiki.php.net/rfc/typecast_array_desctructuring
The patch can be found in MR 5296 located at
>
> Currently PHP supports generic castings like (string), (int), ... maybe is
> time to allow class castings like (ToClass) $fromObject?
I've proposed something similar a year ago:
https://externals.io/message/105332
My intention wasn't to create an object from a scalar, nor was it to limit
to
On 25.03.2020 at 17:06, Dennis Birkholz wrote:
> Hello together,
>
> Am 25.03.20 um 16:46 schrieb Larry Garfield:
>> On Wed, Mar 25, 2020, at 10:29 AM, Ilija Tovilo wrote:
>>> Thanks for your feedback, Larry!
>>>
One possible improvement to either version is allowing an expression on
Currently PHP supports generic castings like (string), (int), ... maybe is
time to allow class castings like (ToClass) $fromObject?
I think that it could be useful to converts to another kind of structure,
or even to reduce object type.
For instance:
---
1. Converting from A to B:
$a = 123;
Hi Rowan
> The problem with that is that it requires a temporary variable to be
> switched on. If I want to switch on, say, a method call, I can write this
> for equality:
I agree. The iffy part would be recognizing if the case expression should be
equated to the switch input or evaluated on
Hi Dennis
Thanks for your feedback!
> you can fall through to other cases without break
You could do the same using the || operator.
> what about the default case?
I haven't described the default case in my proposal but it is exactly what
you'd expect it to be:
```php
$var = true switch {
On Wed, 25 Mar 2020 at 15:29, Ilija Tovilo wrote:
> I don't think this would add any significant benefit over:
>
> ```php
> $x = true switch {
> $x !== null && $x < 5 => ...
> }
> ```
>
The problem with that is that it requires a temporary variable to be
switched on. If I want to switch
Am 25.03.20 um 15:24 schrieb Larry Garfield:
> On Wed, Mar 25, 2020, at 5:57 AM, Nicolas Grekas wrote:
>> Máté suggested this syntax and it has my preference over the one you menton
>> Larry: doubling the visibility keyword could be enough to express
>> read+write access:
>>
>> public private
Hello together,
Am 25.03.20 um 16:46 schrieb Larry Garfield:
> On Wed, Mar 25, 2020, at 10:29 AM, Ilija Tovilo wrote:
>> Thanks for your feedback, Larry!
>>
>>> One possible improvement to either version is allowing an expression on the
>>> left side. That is, rather than doing an equality
On Wed, Mar 25, 2020, at 10:29 AM, Ilija Tovilo wrote:
> Thanks for your feedback, Larry!
>
> > One possible improvement to either version is allowing an expression on the
> > left side. That is, rather than doing an equality match, do a boolean
> > match.
>
> This is how Rust does it:
>
>
Thanks for your feedback, Larry!
> One possible improvement to either version is allowing an expression on the
> left side. That is, rather than doing an equality match, do a boolean match.
This is how Rust does it:
```rust
let x = match ... {
Some(y) if y < 5 => ...
}
```
In other
On Wed, Mar 25, 2020, at 9:27 AM, Ilija Tovilo wrote:
> Hi Michał
>
>
>
> I’m sorry, unfortunately I missed your e-mail and RFC.
>
> Let me know if you’re still working on it and I’ll back off of course.
>
>
>
> Regards
I like the concept, and it looks like you're both on a similar
Hi Michał
I’m sorry, unfortunately I missed your e-mail and RFC.
Let me know if you’re still working on it and I’ll back off of course.
Regards
On Wed, Mar 25, 2020, at 5:57 AM, Nicolas Grekas wrote:
> > > https://hive.blog/php/@crell/improving-php-s-object-ergonomics
> > Named parameters are a pretty tough topic. I think one of the main points
> > of contention is that they make the parameters names part of the API
> > contract, and as
Hi Ilija,
śr., 25 mar 2020 o 13:10 Ilija Tovilo napisał(a):
> Hi everybody!
>
>
>
> A few years ago I suggested adding a new `match` expression to the PHP
> language:
>
> https://externals.io/message/100487
>
>
>
> I arrogantly assumed someone will implement it for me which of course
> didn't
Hi everybody!
A few years ago I suggested adding a new `match` expression to the PHP language:
https://externals.io/message/100487
I arrogantly assumed someone will implement it for me which of course didn't
happen. I'd finally like to get my own hands dirty. I have a very rough,
Hi, internals!
I want to mention, that all existing internal API of Zend could be
accessible via FFI as of PHP7.4. This gives opportunity to implement
userspace operator overloading as a simple PHP package.
I know, that FFI requires some polishing, but it could become a tool to
create
On 23.03.2020 at 18:58, jan.h.boeh...@gmx.de wrote:
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
> to overload operators in their own classes.
It seems to me that the RFC is not sufficiently specific enough
regarding the concatenation of
> 1. This is exposing functionality that already exists for internal classes
>
2. Because this just exposes existing functionality, the amount of
> technical complexity this introduces is very small
>
> 3. As mentioned, this functionality already exists internally and is used
> by GMP, where it
> > https://hive.blog/php/@crell/improving-php-s-object-ergonomics
Thanks Larry, that's a good way to move forward on these topics.
I generally like the ideal of combining property declaration and
> constructors. I've had this on my mind for a while already, and also
> received the same
Hello, internals team!
I would like to propose to rename the PhpToken::getAll() method into the
PhpToken::tokenize(string $source) or PhpToken::lex(string $source) to use
a more meaningful verb word.
After renaming, it will sound more natural: $tokenStream =
PhpToken::tokenize($sourceCode)
Best
On Mon, Mar 23, 2020 at 6:58 PM wrote:
> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>
> Voting closes on 2020-04-06.
>
> Regards,
> Jan Böhmer
>
Thank you.
I voted yes
>
> For details, see the full writeup:
>
> https://hive.blog/php/@crell/improving-php-s-object-ergonomics
An excellent writeup, thank you Larry.
Peter
I'm very sorry, I pressed the reply instead of reply all button, I hope
this fixes it!
I agree that these cases can go horribly wrong. However, my reasoning is
> the following:
> - if a piece of code currently relies on locale-independence (e.g.
> automated data exports) then this
> change
39 matches
Mail list logo
