Morning Internals,
Please review the following RFC:
https://wiki.php.net/rfc/lexical-anon
A look at the patch from those of you that do that would be good :)
Cheers
Joe
I think this solution is merely a band-aid for a more profound architectural
weakness of current PHP setups, where a web server call out to the engine (via
embedding or FastCGI) to execute a script, which causes this recurring
initialization overhead in the first place.
The future is (or
On 4/19/2016 12:02 AM, Lester Caine wrote:
> On 18/04/16 20:08, Fleshgrinder wrote:
>> This is however a useful shortcut and shortcuts are good things in
>> terms of usability if done write. Think of + vs. right click
copy (or any other example of useful keyboard shortcuts).
>
> Except
On 04/19/2016 05:18 PM, Nikita Popov wrote:
On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins wrote:
Morning Internals,
Please review the following RFC:
https://wiki.php.net/rfc/lexical-anon
A look at the patch from those of you that do that would be good
On Tue, Apr 19, 2016 at 6:39 AM, Dmitry Stogov wrote:
> Only one note. I would prefer to use "," instead of "|" as a class name
> separator.
> Especially if "Union types" are not accepted.
> The rest should be fine.
On the other hand if union types is accepted it makes no sense
On Mon, Apr 18, 2016 at 9:28 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > It's about the perception of consistency. "Oh, I can do this! Neat:"
> >
> > function neat(Foo | Bar $a) { ... }
>
> You shouldn't be able to do this, because it makes no sense - why would
> a function
On 04/19/2016 04:09 PM, Levi Morrison wrote:
On Tue, Apr 19, 2016 at 6:39 AM, Dmitry Stogov wrote:
Only one note. I would prefer to use "," instead of "|" as a class name
separator.
Especially if "Union types" are not accepted.
The rest should be fine.
On the other hand if
On 04/19/2016 03:52 PM, Joe Watkins wrote:
Oh, it's confusing text in the RFC, using the word "Interface" ...
that's meant as a placeholder for InterfaceName.
Cheers
Joe
On Tue, Apr 19, 2016 at 1:50 PM, Joe Watkins > wrote:
Morning
Results for project PHP master, build date 2016-04-19 06:35:05+03:00
commit: 60b1441
previous commit:a186ac0
revision date: 2016-04-07 10:26:32+09:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 19/04/16 16:18, Nikita Popov wrote:
On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins wrote:
Morning Internals,
Please review the following RFC:
https://wiki.php.net/rfc/lexical-anon
A look at the patch from those of you that do that would be good :)
Dmitry Stogov wrote on 19/04/2016 15:48:
callable-type is much simpler solution for this use-case.
Usage of Interfaces to check function prototypes is a bit tricky, but
yes, this is a possible use-case.
Do you like to work with framework, that use this trick for every
callback?
If you don't
> On 19 באפר׳ 2016, at 15:46, Dmitry Stogov wrote:
>
> Only one note. I would prefer to use "," instead of "|" as a class name
> separator.
> Especially if "Union types" are not accepted.
> The rest should be fine.
>
+1 from me as well on that. We could have that change as
Dmitry Stogov wrote on 19/04/2016 15:12:
I prefer intuitive concepts, that I may use without rereading manual
again and again.
For this one, I even can't imagine a natural (not over-designed) use
case.
The use case that came to my mind is kind of the other way around from
"syntax sugar for
> What value?
Yes, shorter, more concise (from the programmers perspective) syntax.
Right now, if you do a lot of work with Closures, you have to verify their
interface, the value in having the engine do it for you seems really
obvious.
But also ...
> I thought the same might be implemented
Nikita Popov wrote on 19/04/2016 15:18:
I'd like to suggest an alternative syntax:
$foo = 42;
return new class {
private $bar = $foo;
public function getBar() { return $this->bar; }
}
That is, allow properties inside the anonymous class to be initialized
based on values from the
For me, the proposal is too complex.
I prefer intuitive concepts, that I may use without rereading manual
again and again.
For this one, I even can't imagine a natural (not over-designed) use case.
But this is my personal opinion, and I may be wrong :)
I'll review the code later.
Thanks.
On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins wrote:
> Morning Internals,
>
> Please review the following RFC:
>
> https://wiki.php.net/rfc/lexical-anon
>
> A look at the patch from those of you that do that would be good :)
>
Hey Joe,
The syntax and semantics
On 04/19/2016 05:30 PM, Rowan Collins wrote:
Dmitry Stogov wrote on 19/04/2016 15:12:
I prefer intuitive concepts, that I may use without rereading manual
again and again.
For this one, I even can't imagine a natural (not over-designed) use
case.
The use case that came to my mind is kind
Hi!
> namespace Application;
> function log(Eloquent\Collection | Haldayne\Map $entity) {
> $logger->log($entity->toArray());
> }
This is bad design. It assumes that two completely unrelated classes
have the same function and it means the same. If it's indeed true, we
have a way to express
On 4/19/2016 4:36 AM, Tom Worster wrote:
> On 4/18/16 4:34 AM, Tony Marston wrote:
>
>> I repeat, where was the insult in the post in question? What exactly
>> were the insulting words?
>
> I chose just one example:
>
>> Those who cannot write effective software without these "clever"
>>
On 4/19/2016 6:54 PM, David Zuelke wrote:
> I think this solution is merely a band-aid for a more profound architectural
> weakness of current PHP setups, where a web server call out to the engine
> (via embedding or FastCGI) to execute a script, which causes this recurring
> initialization
On Tue, 2016-04-19 at 23:59 +0800, Lin Yo-An wrote:
>
> Yes! not all global variables will be snapshotted, for now I think
> EG, SPL_G (which saves the autoloader instances), and some object
> instances and zval. Then these opcode could be skipped a lot. So this
> looks like something on top of
> -Original Message-
> From: Fleshgrinder [mailto:p...@fleshgrinder.com]
> Sent: Tuesday, April 19, 2016 8:33 PM
> To: Zeev Suraski ; Larry Garfield
>
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
>
> On
On 4/19/2016 11:41 AM, Zeev Suraski wrote:
> It could actually implement all of them - the two parents, and the child.
> That sounds like a pretty good, explicit way that requires no introduction of
> any new syntax, concepts or engine complexity in order to do what you're
> describing. This
Hi!
> Creating a generic feature that makes sense in a handful of
> situations, while at the same time being one that's
> waiting-to-be-abused in the vast majority of the rest (or as Tom put
> it, a 'footgun') is a pretty poor bargain IMHO.
Completely agree with Zeev here.
It also seems to me
It should be possible to do this for functions and simple classes.
Most probably this will require some engine changes, but this is not a big
problem for major release.
Conditional definition and run-time class inheritance will make significant
troubles.
Thanks. Dmitry.
Larry Garfield wrote on 19/04/2016 16:21:
Which is why I'm not sure I like that approach, because the place I
then call $handler needs to have a conditional in it. There's another
RFC that was posted to Twitter but hasn't made it to the list yet that
seems to solve this better:
We would really like some feedback on this. We know it is a massive
feature, but we have put in quite a lot of research in both the language
implications and implementation challenges. Please ask any questions you
have.
Thanks.
On 18 Apr 2016 11:24 a.m., "Josh Di Fabio"
Hi!
2016-04-19 11:21 GMT-04:00 Larry Garfield :
> On 4/19/16 10:02 AM, Rowan Collins wrote:
>
>> Dmitry Stogov wrote on 19/04/2016 15:48:
>>
>>> callable-type is much simpler solution for this use-case.
>>> Usage of Interfaces to check function prototypes is a bit tricky,
On 4/19/16 10:02 AM, Rowan Collins wrote:
Dmitry Stogov wrote on 19/04/2016 15:48:
callable-type is much simpler solution for this use-case.
Usage of Interfaces to check function prototypes is a bit tricky, but
yes, this is a possible use-case.
Do you like to work with framework, that use this
Hi Nikita,
I was thinking some more about your suggestion:
Nikita Popov wrote on 19/04/2016 15:18:
$foo = 42;
return new class {
private $bar = $foo;
public function getBar() { return $this->bar; }
}
If we allowed this, would it make sense to also allow it in named
classes? This
Hi!
> Except these two are in separate libraries that cannot share an interface.
If these are separate libraries, you can't be sure that method does the
same thing, or even that it will be existing in both.
> An interface is not possible: separate libraries. Duck-typing is not
> appropriate:
Hi!
> More properly - PHP is done in a way that doesn't allow big data
> processing yet :)
>
> LuaJIT may be used for in-kernel packet filtering...
But we're not targeting PHP for in-kernel packet filtering. And we
should not sacrifice language semantics for minuscule gains in
performance.
On Tue, Apr 19, 2016 at 2:13 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > namespace Application;
> > function log(Eloquent\Collection | Haldayne\Map $entity) {
> > $logger->log($entity->toArray());
> > }
>
> This is bad design. It assumes that two completely unrelated
On 4/19/2016 8:48 PM, Zeev Suraski wrote:
>> but it does not help with primitive types. :(
>
> Which is fine. Primitive types can and should get dedicated solutions.
> There's really no need for allowing over creativity with userland-customized
> scalar types.
>
Hmmm... nope. I already
Hi!
> OK. In my opinion, if something is defined as "int" should be always
> "int". Nor "null" neither "undefined".
> This is good for programmers who think like me, for compiler and for
> hardware CPU :)
I understand why it's good, and I agree. The harder question is whether
we can deliver on
>> Except these two are in separate libraries that cannot share an interface.
>
> If these are separate libraries, you can't be sure that method does the
> same thing, or even that it will be existing in both.
This is not true. I can read the documentation for each method and
know they are the
> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Tuesday, April 19, 2016 11:07 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
>
> strawman? A number of people are using it, and it's a flippant and insulting
>
On 4/19/2016 9:39 PM, Stanislav Malyshev wrote:
> Hi!
>
>> Except these two are in separate libraries that cannot share an interface.
>
> If these are separate libraries, you can't be sure that method does the
> same thing, or even that it will be existing in both.
>
>> An interface is not
> -Original Message-
> From: Fleshgrinder [mailto:p...@fleshgrinder.com]
> Sent: Tuesday, April 19, 2016 11:03 PM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
>
> On 4/19/2016 8:48 PM, Zeev Suraski wrote:
> >>
On 04/19/2016 10:53 PM, Stanislav Malyshev wrote:
Hi!
More properly - PHP is done in a way that doesn't allow big data
processing yet :)
LuaJIT may be used for in-kernel packet filtering...
But we're not targeting PHP for in-kernel packet filtering. And we
should not sacrifice language
Hi!
> same thing as "PHP is not $other_language, therefore nothing from that
> language is useful for PHP." Which is an utterly wrong and useless
No, it's not. Nobody claims *nothing* from other languages is useful in
PHP. What is claimed instead that *not everything* from other languages
is
On 4/19/16 1:43 PM, Stanislav Malyshev wrote:
Hi!
Creating a generic feature that makes sense in a handful of
situations, while at the same time being one that's
waiting-to-be-abused in the vast majority of the rest (or as Tom put
it, a 'footgun') is a pretty poor bargain IMHO.
Completely
On 04/19/2016 06:28 PM, Dominic Grostate wrote:
> We would really like some feedback on this. We know it is a massive
> feature, but we have put in quite a lot of research in both the language
> implications and implementation challenges. Please ask any questions you
> have.
thank you all for
On 19 April 2016 at 23:47, Zeev Suraski wrote:
> I fail to see how adding C++ templates to PHP takes it to the next level
> in anything but the complexity scale. Not having them is not preventing
> anybody from doing anything today. Sure, a bunch of frameworks would adopt
> them
I'm not sure it matters, but there is some precedent for this in
JavaScript/ES6:
function foo(bar) {
return new class {
myBar = bar;
getBar() {
return this.myBar;
}
}();
}
console.log(foo('hello').getBar()); // "hello"
(You can actually reference
On Wed, Apr 20, 2016 at 8:22 AM, Sara Golemon wrote:
> On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette
> wrote:
> > about the upper bounds, have you consider another way of describing the
> > constraints, eg:
> >
> > class Box where T is Boxable
> >
> >
On Tue, Apr 19, 2016 at 7:54 PM, guilhermebla...@gmail.com
wrote:
> 1- Even though mentioned, I'd still use "extends" or "implements" instead of
> "is" (which would be a new pseudo-reserved keyword) to enforce data type
> consistency and prevent developers to
On Tue, Apr 19, 2016 at 7:56 PM, Jesse Schalken wrote:
>> class Collection {...
>
> I think the "where T is Traversable, T is Countable" syntax was intended to
> represent the intersection (i.e. a "Countable Traversable"), not the union.
>
> So you would need an
I agree.
On Wed, Apr 20, 2016 at 2:01 PM, Sara Golemon wrote:
> On Tue, Apr 19, 2016 at 7:56 PM, Jesse Schalken
> wrote:
> >> class Collection {...
> >
> > I think the "where T is Traversable, T is Countable" syntax was intended
> to
> > represent the
Hi,
Here are a couple of comments towards Generics support to PHP.
1- Even though mentioned, I'd still use "extends" or "implements" instead
of "is" (which would be a new pseudo-reserved keyword) to enforce data type
consistency and prevent developers to potentially referring to one thing
while
On 20 ? 2016, at 1:10, Marco Pivetta
> wrote:
On 19 April 2016 at 23:47, Zeev Suraski >
wrote:
I fail to see how adding C++ templates to PHP takes it to the next level in
anything but the complexity scale.
On Tue, 2016-04-19 at 17:21 -0600, Rick Widmer wrote:
>
> Are too many of these incompatible shiny things, too fast, the main
> reason so many PHP users are on older versions?
There are many reasons. Often the reason is simply that many cheap
hosting companies or admins don't want to spend time
On 4/19/2016 2:41 PM, Stanislav Malyshev wrote:
I try to share my worry that
some of the things being proposed include seriously complicating PHP's
conceptual model while serving at best infrequent use cases. Simplicity
is a virtue, and we have already lost significant amount of that virtue.
Hi!
> class Collection {...
I am sorry if this sounds harsh, but I really hope we won't have
something like this in PHP. Java templates are complex and weird enough,
adding another layer on top of that to allow type expressions IMHO is
really taking it too far.
--
Stas Malyshev
Hi!
> Are too many of these incompatible shiny things, too fast, the main
> reason so many PHP users are on older versions?
Probably not directly. The reason is PHP 5, as is, is pretty darn good
tool for what it is being used for. Of course, it could be 10x faster,
it could have more extensions
On Wed, 2016-04-20 at 00:09 +0200, Marco Pivetta wrote:
> In Doctrine ORM, having a way to know that a field or parameter is a
> `string | null` or a `int | float` may be the difference between
> knowing
> what kind of column definition is needed for a field at DB level,
> without
> even need for
Hi!
> Any reflector-based system, such as a serializer, an ORM or just a
> dependency injection or configuration loader would be able to do operations
> in a much more precise and less complex way.
This should be solved by annotations. Yes, I know all the story, but it
does not change the fact
On Tue, Apr 19, 2016 at 4:13 PM, Stanislav Malyshev wrote:
>> class Collection {...
>
> I am sorry if this sounds harsh, but I really hope we won't have
> something like this in PHP. Java templates are complex and weird enough,
> adding another layer on top of that to allow
Hi!
> So the Symfony2 routing and Doctrine ORM are academic proof of concepts?
I'm sorry I'm a bit lost about how you got from "prioritizing
'interesting playground' is more suited for academic PoC than for a
mature language" to "Doctrine ORM is an academic PoC". I have little
knowledge on what
On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette wrote:
> about the upper bounds, have you consider another way of describing the
> constraints, eg:
>
> class Box where T is Boxable
>
> this would allow multiple constraints, eg:
>
> class Collection where T is Traversable,
On 20 April 2016 at 00:30, Zeev Suraski wrote:
>
> this is not a make or break feature for PHP.
>
That's why it's called a "feature"
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 20 April 2016 at 01:12, Ronald Chmara wrote:
> On Tue, Apr 19, 2016 at 3:09 PM, Marco Pivetta wrote:
> > In general, improving the type system provides a much more interesting
> and
> > practical playground for any kind of tool that would rely on static
On Tue, Apr 19, 2016 at 3:09 PM, Marco Pivetta wrote:
> In general, improving the type system provides a much more interesting and
> practical playground for any kind of tool that would rely on static
> introspection: IDEs, reflectors, code generators, code inliners,
So,
On 4/19/2016 5:10 PM, Stanislav Malyshev wrote:
In general, improving the type system provides a much more interesting and
practical playground for any kind of tool that would rely on static
That's my point - "more interesting playground" does not sound like a
reason enough to mess with the
> IMHO, it would be AWESOME if we could funnel some of these cycles from new
> syntax and onto other things like parallel processing, async IO, JIT and more
> - which can truly take PHP to the next level. New syntax cannot.
The time investment for those projects is enormous. Not many
> -Original Message-
> From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On Behalf
> Of Levi Morrison
> Sent: Wednesday, April 20, 2016 12:23 AM
> To: Zeev Suraski
> Cc: Larry Garfield ; internals@lists.php.net
> Subject: Re: [PHP-DEV]
> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Friday, April 15, 2016 9:13 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
>
> On 4/15/16 12:28 PM, Christoph Becker wrote:
> > On 15.04.2016 at 17:42, Larry
> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Monday, April 18, 2016 6:18 PM
> To: Marco Pivetta
> Cc: Dan Ackroyd ; Bronisław Białek
> ; PHP internals
> Subject: Re:
On 4/18/16 4:34 AM, Tony Marston wrote:
I repeat, where was the insult in the post in question? What exactly
were the insulting words?
I chose just one example:
> Those who cannot write effective software without these "clever"
> additions to the language are doing nothing but announcing
On 04/18/2016 09:37 PM, Stanislav Malyshev wrote:
Hi!
right.
I don't see any reasons for types, if they are not guaranteed anyway.
Well, we already have parameter types, and they are not guaranteed
either - you can reassign variables.
They guarantee the type of argument on function entry.
> -Original Message-
> From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Sent: Tuesday, April 19, 2016 8:11 AM
> To: Larry Garfield ; internals@lists.php.net
> Subject: Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types
>
>
> > I do agree with the
Only one note. I would prefer to use "," instead of "|" as a class name
separator.
Especially if "Union types" are not accepted.
The rest should be fine.
Thanks. Dmitry.
From: Bronisław Białek
Sent: Sunday, April 17, 2016 19:51
To:
Hello,
Representing the Hoa project community, we have voted yes. Not everyone
was agree (60% yes, 40% no), but my vote reflects the average.
Main argument in favor of no:
* Encourage badly designed API.
Main argument in favor of yes:
* This is not an edge case when dealing with badly
> On 16 Apr 2016, at 11:19 , Lester Caine wrote:
>
> On 16/04/16 06:56, André Rømcke wrote:
This actually summarises many of the problems all of these 'extras' are
creating for very little gain.
'Seconds' is a 'Traditional Property' so is untyped and if
Are $cb1 and $cb2 going to be the same (do the same)?
Is this just a new syntax sugar, or a really new feature?
According to implementation, I think, you shouldn't extend "zend_closure" with
"interface".
If this is a sugar, lets implement it as a sugar (without VM changes).
But may be I
Morning Dmitry,
In your example, they will do the same thing.
Anon classes don't have lexical scope, I have a patch for that, and an
RFC, I'm just tidying it.
Even when anon classes do have lexical scope, there is value in being
able to implement these kinds of interfaces using only a
Oh, it's confusing text in the RFC, using the word "Interface" ... that's
meant as a placeholder for InterfaceName.
Cheers
Joe
On Tue, Apr 19, 2016 at 1:50 PM, Joe Watkins wrote:
> Morning Dmitry,
>
> In your example, they will do the same thing.
>
> Anon classes
78 matches
Mail list logo