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 wouldn'
>
> For details, see the full writeup:
>
> https://hive.blog/php/@crell/improving-php-s-object-ergonomics
An excellent writeup, thank you Larry.
Peter
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 on
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
> > 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 suggesti
> 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
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
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 interesting
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,
incompl
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 ha
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 s
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 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 track.
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 words,
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:
>
> ``
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 match
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 $prop
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 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 {
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 its
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;
$b
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
the
>
> 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
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
https://github.com/php/php-src/pull/529
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, 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 https://wiki.php.net/rfc/typecast_a
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 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
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 unsubscrib
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 Excepti
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 hav
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 Developme
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 {}
>
> $b
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
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.
>
> 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 th
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
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 o
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
Am 24.03.2020 um 11:06 schrieb Sebastian Bergmann:
I voted "no" for the same reason.
I changed my vote to "yes" because of Nikita's arguments.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
> 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.
You can always use anonymous functi
41 matches
Mail list logo
