Le 04/11/2014 03:01, Levi Morrison a écrit :
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
-Ursprüngliche Nachricht-
Von: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] Im Auftrag von
Levi Morrison
Gesendet: Montag, 3. November 2014 19:54
An: Robert Stoll
Cc: PHP Internals
Betreff: Re: [PHP-DEV] Types on the right or on the left
Thoughts?
I think you
Ivan Enderlin @ Hoa wrote:
Excellent RFC, thank you. However, there is no mention about using
`static`, `self` or `parent` as a type (it is possible for an argument).
Something like:
```php
class Singleton {
public function getInstance ( $x, $y): static { … }
}
```
Maybe I miss it
Le 04/11/2014 09:37, Christoph Becker a écrit :
Ivan Enderlin @ Hoa wrote:
Excellent RFC, thank you. However, there is no mention about using
`static`, `self` or `parent` as a type (it is possible for an argument).
Something like:
```php
class Singleton {
public function getInstance (
-Ursprüngliche Nachricht-
Von: Andrea Faulds [mailto:a...@ajf.me]
Gesendet: Montag, 3. November 2014 16:40
An: Robert Stoll
Cc: PHP Internals
Betreff: Re: [PHP-DEV] Types on the right or on the left
On 3 Nov 2014, at 15:07, Robert Stoll p...@tutteli.ch wrote:
It adds the
Hi!
put types only on the right, or only on the left or mix it. I
followed the return type RFC and thus know that many people think it
has to be on the left hand side. Fair enough, I do not have anything
against such a decision. I also have nothing against putting the type
on the right hand
On 04/11/14 06:00, Joe Watkins wrote:
I'm not saying we should not extend the features of phpdbg, but, we
should do it knowing what it actually is, knowing that it is
fundamentally different to xdebug.
Having just hit another 'white screen' problem on a site I'm trying to
update, I do wonder
Hi!
As I do consider personal tastes important, there are times where we should
listen to our users.
It would be nice to take paving the walkways approach, but last time
we tried, IIRC we've got into something very over-engineered. Maybe if
we try again with more restricted scope (i.e. not
On Tue, 2014-11-04 at 09:19 +, Lester Caine wrote:
On 04/11/14 06:00, Joe Watkins wrote:
I'm not saying we should not extend the features of phpdbg, but, we
should do it knowing what it actually is, knowing that it is
fundamentally different to xdebug.
Having just hit another 'white
On 4 November 2014 08:51, Stas Malyshev smalys...@sugarcrm.com wrote:
I don't see why
public Foo function bar() would be so much worse than public function
bar() : Foo
Because when you grep for function bar, in future you'd have to know
the return type too.
I like to think of it as:
function
On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
As I do consider personal tastes important, there are times where we should
listen to our users.
It would be nice to take paving the walkways approach, but last time
we tried, IIRC we've got into something very
On 4 Nov 2014, at 08:51, Stas Malyshev smalys...@sugarcrm.com wrote:
I agree, this is not a very good situation. It would be much better to
take a systematic approach to this, but this is impossible since there
is no systematic approach to strict typing in PHP, just some pieces here
and
On 04/11/14 09:37, Joe Watkins wrote:
On Tue, 2014-11-04 at 09:19 +, Lester Caine wrote:
On 04/11/14 06:00, Joe Watkins wrote:
I'm not saying we should not extend the features of phpdbg, but, we
should do it knowing what it actually is, knowing that it is
fundamentally different to
On Tue, Nov 4, 2014 at 11:28 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
As I do consider personal tastes important, there are times where we
should
listen to our users.
It would be nice to take paving
On Nov 4, 2014 8:54 PM, Benjamin Eberlei kont...@beberlei.de wrote:
On Tue, Nov 4, 2014 at 11:28 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
As I do consider personal tastes important, there are times where
On Tue, Nov 4, 2014 at 12:20 PM, Pierre Joye pierre@gmail.com wrote:
On Nov 4, 2014 8:54 PM, Benjamin Eberlei kont...@beberlei.de wrote:
On Tue, Nov 4, 2014 at 11:28 AM, Pierre Joye pierre@gmail.com
wrote:
On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev smalys...@sugarcrm.com
On 4 November 2014 10:32, Andrea Faulds a...@ajf.me wrote:
On 4 Nov 2014, at 08:51, Stas Malyshev smalys...@sugarcrm.com wrote:
I agree, this is not a very good situation. It would be much better to
take a systematic approach to this, but this is impossible since there
is no systematic
-Ursprüngliche Nachricht-
Von: are.you.winn...@gmail.com [mailto:are.you.winn...@gmail.com] Im Auftrag
von Chris Wright
Gesendet: Dienstag, 4. November 2014 12:51
An: Andrea Faulds
Cc: Stas Malyshev; Robert Stoll; PHP Internals
Betreff: Re: AW: [PHP-DEV] Types on the right or on
Hi!
It would be nice to take paving the walkways approach, but last time
we tried, IIRC we've got into something very over-engineered. Maybe if
we try again with more restricted scope (i.e. not trying to put a DSL
for describing arbitrarily complex data structures into it :) it would
be more
On 4 November 2014 12:17, Robert Stoll p...@tutteli.ch wrote:
-Ursprüngliche Nachricht-
Von: are.you.winn...@gmail.com [mailto:are.you.winn...@gmail.com] Im
Auftrag von Chris Wright
Gesendet: Dienstag, 4. November 2014 12:51
An: Andrea Faulds
Cc: Stas Malyshev; Robert Stoll;
On the basis of 'If it's not broken', what is actually broken, and what
is just a matter of 'I don't like that way of working'?
I have a working Annotation system that has not changed since I started
working with PHP. PHPEclise simple displays the information from the
docblock comments and allows
Hi,
On Tue, Nov 4, 2014 at 2:03 PM, Lester Caine les...@lsces.co.uk wrote:
On the basis of 'If it's not broken', what is actually broken, and what
is just a matter of 'I don't like that way of working'?
I have a working Annotation system that has not changed since I started
working with
Hi!
PHP7 has a wonderful parser, maybe it's possible to provide a general
syntax for annotations with userland hooks for arbitrary data. This
approach can give a tool for framework developers to define a node visitor
for annotations. Alternative way is to define simple key-value storage and
I guess it's worth noting that my *personal* opinion is that I'd also rather
have the function return type declaration on the
left (I'd also like to drop the requirement for the function keyword in
method declarations), but since there are a number
of reasons why this no longer makes sense,
On 04/11/14 13:13, Florian Margaine wrote:
On the basis of 'If it's not broken', what is actually broken, and what
is just a matter of 'I don't like that way of working'?
I have a working Annotation system that has not changed since I started
working with PHP. PHPEclise
Hi,
On Tue, Nov 4, 2014 at 2:28 PM, Lester Caine les...@lsces.co.uk wrote:
On 04/11/14 13:13, Florian Margaine wrote:
On the basis of 'If it's not broken', what is actually broken, and
what
is just a matter of 'I don't like that way of working'?
I have a working Annotation
Currently under *nix, the build system uses a hardcoded location where the
extension is: /ext/ext-name.
Windows is just looking at where the the current config.w32 file is, takes the
directory it is in and handles it like the root of the extension. Just simple,
no hardcoded paths, just
On 04/11/14 14:01, Florian Margaine wrote:
Hi,
On Tue, Nov 4, 2014 at 2:28 PM, Lester Caine les...@lsces.co.uk
mailto:les...@lsces.co.uk wrote:
On 04/11/14 13:13, Florian Margaine wrote:
On the basis of 'If it's not broken', what is actually broken,
and what
is
It sounds like you're suggesting that all work on PHP that does not boil
down to bug fixes be stopped.
I'd suggest an alternative: fork PHP and only merge bugfixes in to your own
version. Best of both worlds, you get to keep your beloved PHP pristine
without any of the cumbersome new features,
On Tue Nov 04 2014 at 9:31:06 AM Lester Caine les...@lsces.co.uk wrote:
Every IDE I've used has always working nicely with docblock annotation
and typing and has provided the facilities people seem to think should
be built in to PHP.
You understand you don't have to use these new features,
On Tue, Nov 4, 2014 at 4:13 AM, Juan Basso jrba...@gmail.com wrote:
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
On 04/11/14 14:51, Kristopher wrote:
Every IDE I've used has always working nicely with docblock annotation
and typing and has provided the facilities people seem to think should
be built in to PHP.
You understand you don't have to use these new features, right? You can
On 04/11/14 14:45, Peter Lind wrote:
I'd suggest an alternative: fork PHP and only merge bugfixes in to your
own version. Best of both worlds, you get to keep your beloved PHP
pristine without any of the cumbersome new features, and the rest of us
can enjoy an evolving language.
In hind sight
On 4 November 2014 16:07, Lester Caine les...@lsces.co.uk wrote:
On 04/11/14 14:51, Kristopher wrote:
Every IDE I've used has always working nicely with docblock
annotation
and typing and has provided the facilities people seem to think
should
be built in to PHP.
You
On 4 Nov 2014, at 11:50, Chris Wright c...@daverandom.com wrote:
On 4 November 2014 10:32, Andrea Faulds a...@ajf.me wrote:
I thought it was inconsistent, but after discussions on StackOverflow, I
don't think it actually is. Return types describe the return type of a
function, not
On 4 Nov 2014, at 10:54, Benjamin Eberlei kont...@beberlei.de wrote:
I agree with Stas that a much simpler approach is probably realistic.
beginning pure speculation here, i see a short array like syntax like:
[foo=bar, bar=baz, baz=[key: value]]
function annotated_fn() {}
Maybe
On 4 Nov 2014, at 14:57, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
just a slight correction:
as far as I can tell, Jakus was ok with the general idea and even with
turning this into the default, but he stated that it should only happen in
a major version (as it would cause a slight BC,
On Tue, Nov 4, 2014 at 5:35 PM, Andrea Faulds a...@ajf.me wrote:
On 4 Nov 2014, at 14:57, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
just a slight correction:
as far as I can tell, Jakus was ok with the general idea and even with
turning this into the default, but he stated that it
On Tue, Nov 4, 2014 at 2:57 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Nov 4, 2014 at 4:13 AM, Juan Basso jrba...@gmail.com wrote:
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
On 04/11/14 16:25, Chris Wright wrote:
An 18 month release cycle for minors and over a decade since the last
major is hardly daily. You do not need to update the libraries when
they start to use the new language features, but if you want to use the
new library features, and those features
Hi!
public Foo function bar() would be so much worse than public function
bar() : Foo
Because when you grep for function bar, in future you'd have to know
the return type too.
Sorry, I do not understand - why to grep for function bar you'd have
to know the type? Just grep for function bar
Hi!
I thought it was inconsistent, but after discussions on
StackOverflow, I don't think it actually is.
If you specify the type once as Foo something and once as something:
Foo then I don't see how there's even a place for discussions that it's
inconsistent.
Return types describe the return
Hi!
In PHP, input types go on the left and output types go on the right.
What is the output type? If I wanted to type a variable - is it input
or output?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To
On 4 Nov 2014, at 17:46, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
public Foo function bar() would be so much worse than public function
bar() : Foo
Because when you grep for function bar, in future you'd have to know
the return type too.
Sorry, I do not understand - why to
On 4 Nov 2014, at 16:41, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Nov 4, 2014 at 5:35 PM, Andrea Faulds a...@ajf.me wrote:
On 4 Nov 2014, at 14:57, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
just a slight correction:
as far as I can tell, Jakus was ok with the general
On 4 Nov 2014, at 17:07, Jakub Zelenka bu...@php.net wrote:
I would really like to see it as default in the next major as it is a
useful feature.
However I don't like adding new flag. The reason for that is that it
becomes useless after 7 is realesed. It would be useful only for 5.6.3
On 3 November 2014 22:45:11 GMT, Chris Wright daveran...@php.net 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.
On 11/04/2014 10:08 AM, Andrea Faulds wrote:
On 4 Nov 2014, at 17:46, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
public Foo function bar() would be so much worse than public function
bar() : Foo
Because when you grep for function bar, in future you'd have to know
the return type
Hi!
All projects mentioned in this thread use:
http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html
That makes a pretty good base spec.
Reading it, it looks pretty big - strictly typed values, named
parameters, default constructors linked to properties, support for enum
Andrea Faulds wrote:
For parameters, the type is of the thing itself:
function foo(Foo $foo, Bar $bar);
Here, $foo is of the type Foo, and $bar is of the type Bar.
But say if we were to add return types like this:
function FooBar qux();
The type of qux isn’t a FooBar, it’s
Hi!
The approach for annotations that I like best would actually be not
annotations, but Python-style decorators. They’re very simple, but
very powerful. They would allow you to do annotations, but also add
extra functionality to functions.
For python-style decorators, at least the way they
Reading it -
http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html -
it looks pretty big - strictly typed values, named
parameters, default constructors linked to properties, support for enum
types, support for typed arrays, separate constant syntax within
annotations.
Hi!
Because if that function has a return type, e.g.:
public function Foo bar()
Then you couldn’t grep for “function bar” because of the Foo.
And that's not what I have proposed. Would anybody actually *read* what
I am proposing? Or reading is optional for discussion now?
If we used
On 04.11.2014 17:34, Andrea Faulds wrote:
In Python, a decorator is a function (or callable object), and you use one
like this:
@some_decorator(foo, bar)
def myfunc():
# function source code here
I wonder how feasible it would be to add something like this and allow
On Mon, Nov 3, 2014 at 10:10 PM, Stas Malyshev smalys...@sugarcrm.com
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
On 4 Nov 2014, at 18:33, Stas Malyshev smalys...@sugarcrm.com wrote:
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();
It’d be inconsistent with normal function declarations which would have to
have Foo after function.
What's normal function
Hi!
I'm -1 on this RFC, because I think this only further encourages
ill-advised usages of unserialize() on user-provided strings. I don't
I guess that's where we disagree. I think that security is a layered
approach (see more here:
Hi!
But it’s rather weird for closures:
$foo = Foo function () {
};
Not much weirder than:
$foo = static function () { ... }
which we already have. Putting modifiers in front of the function is
nothing foreign to PHP.
--
Stanislav Malyshev, Software Architect
SugarCRM:
On 4 Nov 2014, at 18:27, Stas Malyshev smalys...@sugarcrm.com wrote:
For python-style decorators, at least the way they work in Python, we'd
need to organize our function tables differently, as Python just
replaces the function with another one while decorating, and I'm not
sure it'd be as
On Tue, Nov 4, 2014 at 7:45 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
I'm -1 on this RFC, because I think this only further encourages
ill-advised usages of unserialize() on user-provided strings. I don't
I guess that's where we disagree. I think that security is a layered
I agree with Nikita.
Adding an extra argument for one particular security related case looks
weird.
Will we add more arguments for others?
I would also prefer options array and [] instead of 'false'.
unserialize($string, array('allowed_classes'=[]));
It's also more readable :)
Thanks. Dmitry.
On Tue, Nov 4, 2014 at 11:48 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
But it’s rather weird for closures:
$foo = Foo function () {
};
Not much weirder than:
$foo = static function () { ... }
which we already have. Putting modifiers in front of the function is
If this is difficult, you can do in PHP 7.0 simple realization
annotation/facades, in versions 7.x to develop and refine.
Most importantly, define the syntax and semantics annotation/facades, for a
version of PHP 7.0
Demand in annotation/facades is very high, ~80% of all popular frameworks
their
Hi!
To clarify: I don't think it makes sense to add an additional security
option, if we cannot say that unserialize() is to our knowledge *fully*
That's where we disagree. I think security is a spectrum, and you can
make it better. It looks like you think it's binary - either it is
*fully*
Hi,
On Tue, Nov 4, 2014 at 6:14 PM, Andrea Faulds a...@ajf.me wrote:
On 4 Nov 2014, at 17:07, Jakub Zelenka bu...@php.net wrote:
I would really like to see it as default in the next major as it is a
useful feature.
However I don't like adding new flag. The reason for that is that it
In Python, decorators are very
powerful for modifying function behavior (i.e., attaching pre/post
conditions to functions or doing some things phpunit does is really
easy) but it is too much for just attaching data.
FWIW (and I apologize if this is just adding to the noise), one of the most
I like the idea, especially list($a, $b, ...$c) = ...
Looks like Prolog's [A, B | C] = ..., unfortunately it won't provide the
same semantic and performance.
Implementation needs to be reviewed, but I think it must not affect
existing opcodes.
Thanks. Dmitry.
On Tue, Nov 4, 2014 at 1:45 AM,
Hi,
As one of the original authors of both Doctrine Annotations and previous
RFC of native Annotations in PHP, I can go thoroughly on every specific
detail about challenges of design decisions to make.
Primarily, I do not see docblocks as the right place to store class'
metadata information.
On 4 Nov 2014, at 20:06, Jakub Zelenka bu...@php.net wrote:
That's a good point. However I still think that there are more advantages for
making this the default. I like mainly the idea that
json_decode(json_encode($a)) = $a for all floats which is not the case at the
moment. Also it
On 4 Nov 2014, at 18:14, Rowan Collins rowan.coll...@gmail.com wrote:
On 3 November 2014 22:45:11 GMT, Chris Wright daveran...@php.net 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
On 04/11/14 20:18, guilhermebla...@gmail.com wrote:
Primarily, I do not see docblocks as the right place to store class'
metadata information. Metadata != Comments.
We use comment wrappers in many places to hide secondary material from
other processes. Just rename docblocks - metadata ... what
2014-11-04 9:51 GMT-08:00 Stas Malyshev smalys...@sugarcrm.com:
Hi!
I thought it was inconsistent, but after discussions on
StackOverflow, I don't think it actually is.
If you specify the type once as Foo something and once as something:
Foo then I don't see how there's even a place for
Just as a note: /** and /* are already treated differently by the
parser (T_DOC_COMMENT vs. T_COMMENT, this difference is also present
in opcache).
Anyway, metadata/annotations/whatever you want to call them should be
seperated from comments and verbal descriptions on a
syntax level, not just by
Hi!
Primarily, I do not see docblocks as the right place to store class'
metadata information. Metadata != Comments.
I personally regard this as a kind of superstition. There's nothing
wrong with extending what can be in comments. In fact, Javascript was
officially HTML comment for years, and
On 04/11/14 21:24, Sebastian B.-Hagensen wrote:
Just as a note: /** and /* are already treated differently by the
parser (T_DOC_COMMENT vs. T_COMMENT, this difference is also present
in opcache).
Anyway, metadata/annotations/whatever you want to call them should be
seperated from comments
On 4 Nov 2014, at 21:31, Stas Malyshev smalys...@sugarcrm.com wrote:
This brings the next piece of the puzzle. We have to update lexical and
semantical understanding of PHP. Taking Java's approach (@) does not
work in PHP, because it conflicts with error supression. Same thing
Except for
Hi,
By dealing with annotations in docblocks will force the Annotations parser
to *much* smarter than you imagine.
Currently in Doctrine Annotations implementation, @param and @Param are
considered different not only by first character to be uppercased, but
rather because a class also exist in
Sorry, I forgot to add references to how we fixed emails handling. It got
split in 2 places:
- Initial root level annotation
https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/DocParser.php#L350
- Subsequent root level annotations
Good evening,
A lot of RFCs have been rejected because, while they proposed a feature people
would like, the details were problematic. This has lead to these features
sometimes being considerably delayed.
So, in order to do something about this, here’s an idea: Why not hold two
different
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();
It’d be inconsistent with normal function declarations which would have to
have Foo after function.
I don't understand that inconsistency.
public Foo function bar() { }
looks perfectly sane
On 11/04/2014 04:42 PM, Levi Morrison wrote:
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();
It’d be inconsistent with normal function declarations which would have to
have Foo after function.
I don't understand that inconsistency.
public
On Tue, Nov 4, 2014 at 5:55 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/04/2014 04:42 PM, Levi Morrison wrote:
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();
It’d be inconsistent with normal function declarations which would have to
have
On Tue, Nov 4, 2014 at 6:05 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Except `static function()` and `static function foo()` already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.
If it is possible, why it's not
Except `static function()` and `static function foo()` already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.
If it is possible, why it's not the part of the RFC? Probably because
there's not much place where it would make
I apologize: my baby managed to send my email premature. I'm not even
sure what hotkey he hit ^^
Except `static function()` and `static function foo()` already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.
If it is
https://bugs.php.net/bug.php?id=68331
I was hoping the submitter (or one of their coworkers who commented on
it) would reach out to the list themselves to get more information
since I don't know the whole situation. I did ask them to...
Story thus far:
Yasuo's session-lock-ini RFC [1] in
Hi Rasmus,
Sorry for delay, I'm just back to work after ZendCon and holidays.
opcache.revalidate_freq is PHP_INI_ALL on purpose.
Scripts that generate and include the same file again and again should set
it to 0 to check for modification on each include.
I didn't get what did you meant by but
Hi!
What arguments do you have in favor of doing `return_type function
identifier ( parameter_list )`? So far I haven't heard any
We already using type before entity for parameter typing, and it is a
natural way to do it, both from linguistic perspective (in English, we
say green house, not
I reformatted Stas' arguments to a form better for point-by-point
discussion; I'm sorry if I lost too much information when doing so.
1) It's more natural to do a prefixed type.
This is the same thing that I am claiming, just from the opposite viewpoint.
2) Type prefixed parameters and type
Hi!
C++11 adds suffixed types for returns despite having prefixed types
for everything else, including previous return types.
C++ does it for entirely different reasons, related to scoping, and it
still has auto type at the beginning. In any case, I'd be very vary
taking late C++ hacks as a
On 11/04/2014 06:33 PM, Dmitry Stogov wrote:
Hi Rasmus,
Sorry for delay, I'm just back to work after ZendCon and holidays.
opcache.revalidate_freq is PHP_INI_ALL on purpose.
Scripts that generate and include the same file again and again should
set it to 0 to check for modification on
On Nov 4, 2014 5:28 AM, Stas Malyshev smalys...@gmail.com 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.
Hello,
I've submitted a PR to add IDN support in PHP streams. The way it's done
will allow easy IDN domain validation in ext/filter too.
Can you review this PR please?
https://github.com/php/php-src/pull/890
--
Kévin Dunglas
Consultant et développeur freelance
http://dunglas.fr
Tél. : 06 60
93 matches
Mail list logo
