Removing references would be great for implementation , but this doesn't look
realistic in context of PHP language.
HHVM already made steps into this direction with Hack.
Thanks. Dmitry.
From: Dan Ackroyd
Sent: Friday, October 25, 2019 18:40
To: Dmitry Stogov
On Fri, 25 Oct 2019 at 14:27, Dmitry Stogov wrote:
>
> // <= 100 type checks on a single assignment
That code contains a reference that is re-used 100 times.
I personally prefer not to use references at all, but if people do
want to use them, we could put a note that references are bad for
Hi Nikita,
in your results, assignment to typed reference is ~3 time slower without JIT
and ~10 times slower with JIT.
But this is not the worst case. I can simple craft a script where single
assignment will lead to hundreds type checks.
ref =& $ref;
}
}
for ($i = 0; $i < 100; $i++) {
> Le 25 oct. 2019 à 04:36, Ken Stanley a écrit :
>
> So far it seems like the biggest concern(s) is that we would most likely
> repeat the use of variables (nothing new), and that there are other ways to
> do the same thing (again, nothing new). And of course the most valid
> argument of all:
Hi internals,
Voting on the union types RFC is now open.
Proposal:
https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
Voting: https://wiki.php.net/rfc/union_types_v2
If you'd like to take a look at the discussions on this topic, those would
be:
Pull request:
On Fri, 25 Oct 2019 at 12:27, Andreas Hennings wrote:
>
> On Fri, 25 Oct 2019 at 12:21, Rowan Tommins wrote:
> >
> > On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote:
> >
> > > But I think this functionality should be of something like pipeline
> > > operator:
> > >
> > > // send tmp variable
On Fri, 25 Oct 2019 at 12:21, Rowan Tommins wrote:
>
> On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote:
>
> > But I think this functionality should be of something like pipeline
> > operator:
> >
> > // send tmp variable to the next expression unconditionally
> > $ret = $_SERVER['fname'] |>
> Le 25 oct. 2019 à 01:23, Sara Golemon a écrit :
>
> Just testing the waters: Is there any appetite to have AND and OR behave
> more like Pythons operator?
> Instead of now:
> (a or b) => bool(true) if either of a or b are true
> (a and b) => bool(true) is either of a or b are true
>
>
On Wed, Oct 23, 2019 at 5:42 PM Dmitry Stogov wrote:
> Hi Nikita,
>
> I checked the Union Type implementation, and it more or less good. I mean,
> it implements the RFC in almost the best way.
> However, as I don't like the RFC itself. Especially, unions of multiple
> classes and interference
On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote:
> But I think this functionality should be of something like pipeline
> operator:
>
> // send tmp variable to the next expression unconditionally
> $ret = $_SERVER['fname'] |> $user->setName($$);
> // send tmp variable to the next expression
On Fri, 25 Oct 2019 at 03:37, Ken Stanley wrote:
> This got rejected for being too large???
>
If you trim the quotes in your replies to just the parts needed for
context, it keeps the message shorter, and makes it much easier to read
through.
> > The fact that it’s a counterpart to an
On Thu, 24 Oct 2019 at 13:47, Rowan Tommins wrote:
> I think this performance impact is a real concern; PHP is the only language
> I know of which implements type checks entirely at run-time in production
> code, and we should ask ourselves if that's definitely the right approach.
>
As they are
> Le 25 oct. 2019 à 04:31, Ken Stanley a écrit :
>
> If the parameter is null able, I may need to add an if condition to look up
> a sane default value when the parameter comes through as null. It would be
> much more succinct (and less error prone) to be able to say something like
>
> /**
>
13 matches
Mail list logo
