On Nov 4, 2014 8:50 AM, "Levi Morrison" wrote:
> Whether the annotation is in a comment or not, the idea of changing
> behavior at runtime based on the annotation is pretty magical. I
> highly discourage using this type of feature whether it's in a comment
> or not.
>
> I will certainly vote no o
On Mon, 2014-11-03 at 21:03 +, Derick Rethans wrote:
> Hi,
>
> This is based on an email conversation between Joe Watkins and me. I
> asked him
> what the original scope of phpdbg was, and I've summarized his reply
> here:
>
> - PHPDBG was originally envisioned as a "gdb" for the Zend VM, w
Hi,
I opened a pull request[1] in order to solve the bug 50224[2] and it ended
creating this pull request to add a new flag called
JSON_PRESERVE_FRACTIONAL_PART on json_encode function. This flag will make
the json encode to output float number always with decimal part, even when
it is 0.
Current
On Mon, Nov 3, 2014 at 7:01 PM, Levi Morrison wrote:
> Dear Internals,
>
> I am pleased to announce that the return type RFC is now open for
> voting[1]. Note that the implementation needs a bit of cleaning up
> before merging should the RFC be accepted; Dmitry has already
> volunteered to help wi
Dear Internals,
I am pleased to announce that the return type RFC is now open for
voting[1]. Note that the implementation needs a bit of cleaning up
before merging should the RFC be accepted; Dmitry has already
volunteered to help with that, but more eyes are welcome.
A couple of things have chan
Hi!
> - PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb
> like commands to debug, and step through code.
That was also my impression when the RFC was discussed.
Now, I do not object in principle on growing the scope of phpdbg. But
this needs to be done the right way if it'
Hi!
> I wonder how often the final parameter will simply be
> get_declared_classes()
That would be quite dangerous as there are a lot of classes in the
extensions, not all of them are your friends. Also, in a big projects,
you don't always know which classes may be currently loaded.
--
PHP Inter
Nothing magical in the annotations no, they very obvious.
It gives you the to declare logic and meta data.
I do not like annotated in comments, I like the implementation of
annotation in C#
2014-11-04 0:49 GMT+02:00 Levi Morrison :
> On Mon, Nov 3, 2014 at 10:39 AM, Larry Garfield
> wrote:
> > O
On 3 November 2014 21:10, Stas Malyshev wrote:
> Hi!
>
> I'd like to put to vote my proposal about the filtered unserialize():
>
> https://wiki.php.net/rfc/secure_unserialize
>
> It was discussed a number of times before and I think it is time to have
> a decision on it. If you need any clarificat
Hi,
Derick wrote:
> I asked him what the original scope of phpdbg was,...
> And I very much agree that the above bullet points,
The original scope of a project and what it should be in the future
are not related always related. Please don't pretend that they're the
same thing.
Derick wrote:
> I'
> On 3 Nov 2014, at 22:45, Chris Wright wrote:
>
> I'd like to open discussion a relatively simple and clear-cut RFC, either
> people will like it or they won't, there isn't a lot more to say here than
> what's in the RFC so please have a read.
>
> https://wiki.php.net/rfc/additional-splat-usag
On 3 November 2014 22:45, Chris Wright wrote:
> Good evening list,
>
> I'd like to open discussion a relatively simple and clear-cut RFC, either
> people will like it or they won't, there isn't a lot more to say here than
> what's in the RFC so please have a read.
>
> https://wiki.php.net/rfc/addi
Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC, either
people will like it or they won't, there isn't a lot more to say here than
what's in the RFC so please have a read.
https://wiki.php.net/rfc/additional-splat-usage
Thanks, Chris
On Mon, Nov 3, 2014 at 10:39 AM, Larry Garfield wrote:
> On 11/3/14, 10:37 AM, Stefan Neufeind wrote:
>>
>> On 11/03/2014 05:26 PM, Pierre Joye wrote:
>>>
>>> On Nov 4, 2014 1:24 AM, "Jonah H. Harris" wrote:
On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
> There are
> On 3 Nov 2014, at 21:33, Stas Malyshev wrote:
>
>> Coming late to the discussion. Was there any discussion to make the
>> new argument a callback instead? Pass it the fully-qualified class
>> name, have it return true (the class should be loaded) or false (the
>> class should not be loaded). D
> On 3 Aug 2014, at 22:50, Andrea Faulds wrote:
>
> Good evening,
>
> I am proposing two new RFCs. As they are both inter-related and
> complementary, with the second having the first as a prerequisite, I’m making
> just a single email to cover both:
>
> https://wiki.php.net/rfc/closure_appl
> On 24 Oct 2014, at 00:36, Andrea Faulds wrote:
>
> Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
After further though, I am withdrawing this RFC. It’s confusing and a
half-baked solution to the problem. Also, I’m not sure I like the idea of
variable visibility accessors i
Hi!
> Coming late to the discussion. Was there any discussion to make the
> new argument a callback instead? Pass it the fully-qualified class
> name, have it return true (the class should be loaded) or false (the
> class should not be loaded). Deprecate the `unserialize_callback_func`
> mechanism
On Mon, Nov 3, 2014 at 10:10 PM, Stas Malyshev wrote:
> I'd like to put to vote my proposal about the filtered unserialize():
>
> https://wiki.php.net/rfc/secure_unserialize
Hi,
Coming late to the discussion. Was there any discussion to make the
new argument a callback instead? Pass it the fully
> Am 03.11.2014 um 22:03 schrieb Derick Rethans :
>
> Hi,
>
> This is based on an email conversation between Joe Watkins and me. I
> asked him
> what the original scope of phpdbg was, and I've summarized his reply
> here:
>
> - PHPDBG was originally envisioned as a "gdb" for the Zend VM, with
Hi!
I'd like to put to vote my proposal about the filtered unserialize():
https://wiki.php.net/rfc/secure_unserialize
It was discussed a number of times before and I think it is time to have
a decision on it. If you need any clarifications on the proposal, please
do not hesitate to ask.
--
Stan
Hi,
Why should phpdbg scope be limited, and not extended? As far as I know,
xdebug is nowhere like an official php project, so overlap shouldn't be an
issue.
I'm not saying phpdbg has to be extended, but I'm wondering why it should
be limited.
Regards,
On Mon, Nov 3, 2014 at 10:03 PM, Derick Re
Hi,
This is based on an email conversation between Joe Watkins and me. I
asked him
what the original scope of phpdbg was, and I've summarized his reply
here:
- PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb
like commands to debug, and step through code.
- Support for b
Hi!
> Again, an unfair comparison. Hack isn’t intended to be a completely
I'm not sure what you refer to by "fair". Hack is not "intended", but IS
a separate language - just read the manual and you will see, it is a new
language which borrows some syntax from PHP. Just read their own site:
Hack
> On 3 Nov 2014, at 19:48, Stas Malyshev wrote:
>
> Hi!
>
>> This is an unfair comparison. Hack is a compatible superset of PHP,
>> much like TypeScript is a compatible superset of JavaScript.
>
> So? PHP once borrowed Perl syntax, and Java syntax, and so on. Hack
> borrowed PHP syntax, and th
Hi!
> This is an unfair comparison. Hack is a compatible superset of PHP,
> much like TypeScript is a compatible superset of JavaScript.
So? PHP once borrowed Perl syntax, and Java syntax, and so on. Hack
borrowed PHP syntax, and that's great. But that doesn't mean what they
do in their own langu
> On 3 Nov 2014, at 19:28, Stas Malyshev wrote:
>
> Hi!
>
>> PHP doesn’t need more inconsistency, sure, but we must be practical
>> here. It is bad if PHP and Hack have the same feature with different
>> syntax, it will cause developer confusion and further segment the
>> communities.
>
> Give
Hi!
> PHP doesn’t need more inconsistency, sure, but we must be practical
> here. It is bad if PHP and Hack have the same feature with different
> syntax, it will cause developer confusion and further segment the
> communities.
Given that Hack is a different language, which was designed AFAIK wit
> Thoughts?
I think you didn't follow the mailing list or read the return types
RFC carefully if you think putting the return type before the function
name is good at all. Also, why are you starting this conversation now
instead of months ago or even a couple weeks ago when I asked for
feedback on
On 11/3/14, 10:37 AM, Stefan Neufeind wrote:
On 11/03/2014 05:26 PM, Pierre Joye wrote:
On Nov 4, 2014 1:24 AM, "Jonah H. Harris" wrote:
On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
There are no current concrete plans and currently nothing being
seriously
discussed (at least, not
On 11/03/2014 05:26 PM, Pierre Joye wrote:
> On Nov 4, 2014 1:24 AM, "Jonah H. Harris" wrote:
>>
>> On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
>>
>>> There are no current concrete plans and currently nothing being
> seriously
>>> discussed (at least, not publicly; I don't know if anyone
On Nov 4, 2014 1:24 AM, "Jonah H. Harris" wrote:
>
> On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
>
> > There are no current concrete plans and currently nothing being
seriously
> > discussed (at least, not publicly; I don't know if anyone has anything
in
> > pipeline that they haven't ann
> On 3 Nov 2014, at 15:07, Robert Stoll wrote:
>
> It adds the type hint on the right hand side of the function (of the
> identifier). In contrast to parameters where the
> type hint is placed on the left hand side of the identifier.
> Mixing both, having some types on the left and others on th
On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
> There are no current concrete plans and currently nothing being seriously
> discussed (at least, not publicly; I don't know if anyone has anything in
> pipeline that they haven't announced yet). The three RFCs you linked above
> are all basica
On 30 October 2014 11:31, Matteo Beccati wrote:
> Hi,
>
> On 30/10/2014 08:03, Trevor Suarez wrote:
> > Good early morning (late night for me) internals!
> >
> > I would like to propose a small addition be made to the DateTime date
> > format constant definitions.
> >
> > https://github.com/php/p
Heya,
Its seems to me that more and more RFC are proposed to augment PHP's syntax
with some form of additional type hints.
The following RFC proposes to add a type hint for the return type of a
function/method:
https://wiki.php.net/rfc/returntypehinting
It adds the type hint on the right hand s
On 3 November 2014 13:56, Alex Sky wrote:
> Hello!
>
> There are at least three of the RFC for native work with annotations.
> https://wiki.php.net/rfc/reflection_doccomment_annotations
> https://wiki.php.net/rfc/annotations-in-docblock
> https://wiki.php.net/rfc/annotations
>
> I would like to k
Hello!
There are at least three of the RFC for native work with annotations.
https://wiki.php.net/rfc/reflection_doccomment_annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/annotations
I would like to know how plans in PHP 7 support annotations in the code?
2014-10-30 19:23 GMT+01:00 Sherif Ramadan :
> Hello Internals,
>
> I've been meaning to write up a full-blown RFC for introducing a new
> standardized HTTP interface for PHP core for some time now. I figure now
> with PHP 7 on the road map this might be a good time to start this
> discussion since
On 03/11/2014 12:55, Matteo Beccati wrote:
> [re: PQexec] Going from memory it is also used with
> PGSQL_DISABLE_PREPARES (5.6+) if there are no bound parameters.
Actually, that was true only in the earlier versions of the feature.
I've decided not to do that to avoid behaviour changes and unplea
On 03/11/2014 12:40, Rowan Collins wrote:
> When using a one-shot call to query() with multiple statements (e.g.
> create temp table; populate temp table; select results) it's actually
> necessary with Postgres to switch on emulation, and for that
> emulation to allow multiple queries even though t
On 3 November 2014 09:18:08 GMT, Matteo Beccati wrote:
>Hi all
>
>Resuming this once again after Anthony's blog post...
>
>On 16/10/2014 18:10, Ferenc Kovacs wrote:
>> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf
>wrote:
>>> I do agree that the default should probably be server-side since it
>
Hi all
Resuming this once again after Anthony's blog post...
On 16/10/2014 18:10, Ferenc Kovacs wrote:
> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf wrote:
>> I do agree that the default should probably be server-side since it is
>> the least surprising. We just need to make it very very cle
> On 03 Nov 2014, at 02:21, Dan Ackroyd wrote:
>
> On 2 November 2014 15:10, Rowan Collins wrote:
>> Wait, what does session handling have to do with any of this?
>
> Sorry, I completely failed to write what I was trying to say there.
>
> I meant that like the session handling functions and s
44 matches
Mail list logo