Hi internals (again),
Recently I’ve done a small assessment on how feasible it is to remove ext/ereg
from the project for the next major version. This is the result (so far):
https://github.com/datibbaw/php-src/compare/kill-ereg
I’ve replaced two instances of ereg with their pcre equivalents, O
On 31 Aug, 2014, at 12:40 pm, Stas Malyshev wrote:
> Hi!
>
>> This is just a thought; could we delay the call to
>> `zend_call_destructors` ONLY IF there’s output buffering taking place
>> (i.e. ob_get_level() > 0)?
>
> That wouldn't help - imagine this:
> 1. ob_start is set
> 2. shutdown is s
Hi!
> This is just a thought; could we delay the call to
> `zend_call_destructors` ONLY IF there’s output buffering taking place
> (i.e. ob_get_level() > 0)?
That wouldn't help - imagine this:
1. ob_start is set
2. shutdown is starting
3. ob functions shut down, call function foo
4. function foo
On 31 Aug, 2014, at 6:12 am, Stas Malyshev wrote:
> Hi!
>
>> There’s no real objective measure with which I can answer such
>> questions :)
>>
>> The closest I could come to a rebuttal is if there’s no real need to
>> make the syntax so restrictive, why not make it less restrictive?
>
> "Why
On 31 Aug, 2014, at 9:33 am, Stas Malyshev wrote:
> Hi!
>
> I was looking at bug https://bugs.php.net/bug.php?id=67644 and it looks
> like we have a bit of a problem with output buffering and dtors on
> shutdown. Basically, right now our code looks like this:
>
> /* 2. Call all possible
Hi!
I was looking at bug https://bugs.php.net/bug.php?id=67644 and it looks
like we have a bit of a problem with output buffering and dtors on
shutdown. Basically, right now our code looks like this:
/* 2. Call all possible __destruct() functions */
zend_try {
zend
On 30/08/2014 22:26, Robert Williams wrote:
function foo() {
$string = <<<
THEEND
This is the document text. Any
whitespace appearing in a column
that’s before the starting token
is automatically ignored for all
lines.
THEEND;
I like this idea,
Hi!
> There’s no real objective measure with which I can answer such
> questions :)
>
> The closest I could come to a rebuttal is if there’s no real need to
> make the syntax so restrictive, why not make it less restrictive?
"Why not" is usually not a very good reason for a change in the languag
If the syntax of heredocs/nowdocs is to be loosened, the biggest aspect I’d
like to see addressed is indentation. I can certainly see how it would be nice
to loosen the restrictions around the post-closing-token newline to allow
easier use in places like array definitions, but, I’ve never run in
Hi,
Manual: "Also, the identifier must follow the same naming rules as any
other label in PHP: it must contain only alphanumeric characters and
underscores, and must start with a non-digit character or underscore."
RFC: "Ends a quotation when the closing identifier is followed by a
newline o
Hi internals,
I was going through the bug list and found this report:
https://bugs.php.net/bug.php?id=38409
It discusses the fact that `parse_ini_file()` and `parse_ini_string()` throw
away type information; for instance, the flag “on” doesn’t translate into a
bool(true) but string(“1”).
The
On Aug 30, 2014 3:26 PM, "Matteo Beccati" wrote:
>
> On 30/08/2014 14:03, Chris Wright wrote:
> > On 30 August 2014 12:53, Matteo Beccati wrote:
> >> Even though size_t allows "huge" strings, would it be so bad to throw
an
> >> error when one tries to create a string longer than 2^32 bytes,
> >>
On 30/08/2014 14:03, Chris Wright wrote:
> On 30 August 2014 12:53, Matteo Beccati wrote:
>> Even though size_t allows "huge" strings, would it be so bad to throw an
>> error when one tries to create a string longer than 2^32 bytes,
>> regardless of memory_limit?
>
> This would be an unnecessary
On 30 August 2014 12:53, Matteo Beccati wrote:
> On 29/08/2014 23:58, Anatol Belski wrote:
>> On Fri, August 29, 2014 18:34, Xinchen Hui wrote:
>>> if a string is bigger than 2^32... I think there must be a bug :)
>>>
>> Only for this case you mean, or generally? As we safe with memory_limit
>
On 29/08/2014 23:58, Anatol Belski wrote:
> On Fri, August 29, 2014 18:34, Xinchen Hui wrote:
>> if a string is bigger than 2^32... I think there must be a bug :)
>>
> Only for this case you mean, or generally? As we safe with memory_limit
> anyway.
Even though size_t allows "huge" strings, wo
On Sat, 2014-08-30 at 18:33 +0800, Tjerk Meesters wrote:
>
> The closest I could come to a rebuttal is if there’s no real need to
> make the syntax so restrictive, why not make it less restrictive?
>
This is a good criterion when adding a new syntax. A change to existing
syntax features needs fur
On Sat, Aug 30, 2014 at 2:33 AM, Tjerk Meesters
wrote:
> Hi internals,
>
> I would like to propose a few changes to our heredoc / nowdoc scanner to
> make it less awkward to use inside other constructs.
>
> https://wiki.php.net/rfc/heredoc-scanner-loosening
>
> Let me know your thoughts :)
>
+1
Hi Stas,
On 30 Aug, 2014, at 2:08 pm, Stas Malyshev wrote:
> Hi!
>
>> I would like to propose a few changes to our heredoc / nowdoc scanner to
>> make it less awkward to use inside other constructs.
>>
>> https://wiki.php.net/rfc/heredoc-scanner-loosening
>>
>> Let me know your thoughts :)
>
18 matches
Mail list logo
