Am 29.1.2013 um 15:58 schrieb Derick Rethans der...@php.net:
I wouldn't bother making it work with ZTS. If you want performance, you
shouldn't be using it, and the other case I heard was pthreads in
which case it plays no role,as all of the script is in memory anyway
for the duration of
Hi,
I don't really like to write every time a long 'function()', only for passing
a little callback like 'function ($v) { var_dump($v); }'...:
Nice proposal, but writing the last argument outside of the function call could
be confusing... An user-function is not a language construct (like
Hi!
https://github.com/php/php-src/pull/290
How should I name the ini parameter?
max_magic_calls (magic ?=? everything which is not a direct function call)
max_implicit_calls
max_implicit_function_calls
Or what do you think is the most self documenting name?
Bob
p.s.: There is no reason why
Am 25.2.2013 um 17:45 schrieb Johannes Schlüter johan...@schlueters.de:
On Mon, 2013-02-25 at 16:36 +0100, Bob Weinand wrote:
p.s.: There is no reason why not to fix this in this way, I think, as
you can test at how may iterations the stack will overflow and set the
limit near to this maximum
Am 25.2.2013 um 19:08 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
p.s.: There is no reason why not to fix this in this way, I think,
There actually is. First, any option modifying engine behavior creates a
compatibility problem, since now the code that needs to work with it has
Am 25.2.2013 um 19:10 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
Yes, but you can do an approximation. And in 99.999% of the cases 100
will be enough. I can hardly imagine a case where you need to do over
100 implicit function calls. They should fit in every normal stack size of
Forgotten to cc to internals list:
Am 25.2.2013 um 19:50 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
You may use recursive functions (which are limited by the memory_limit),
but if you use recursive magics, it's a design error. This is not the purpose
of magics (,
Am 25.2.2013 um 22:01 schrieb Johannes Schlüter johan...@schlueters.de:
On Mon, 2013-02-25 at 20:36 +0100, Bob Weinand wrote:
I can increase the default limit to 1000, but if it is too high it has
exactly no sense.
Which is exactly the issue i mentioned about being a good default
We
Am 25.2.2013 um 23:07 schrieb Sara Golemon poll...@php.net:
(For me, it's changes like Sara's trailing comma proposal that are too
small to have needed an RFC)
When it comes to changing syntax, there is no such thing as too small
of an RFC IMO. Runtime changes can occasionally be
Am 26.02.2013 um 00:08 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
Don't consider it as a syntax change, only as a bugfix. It must have been a
bug, that this degree of conformity was not yet reached. :-P
If it changes syntax, it's by definition a syntax change. It does not
matter
May someone merge this PR (#290) as there are no arguments against it?
Or do I have to wait a little bit? (How long?)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 27.2.2013 um 22:01 schrieb Ferenc Kovacs tyr...@gmail.com:
I'm not sure that the current options covering all cases.
How should one vote if he/she thinks that this should go into the next
release after 5.5?
Currently their only option would be to vote for no, which isn't doesn't
really the
Hi!
As this seem to require a RFC, here is it:
https://wiki.php.net/rfc/unset_bool
Please feedback,
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
false. It's like unset($setValue) unset($undefined).
I've clarified this in the RFC; thank you.
Bob Weinand
Am 06.03.2013 um 22:24 schrieb Steve Clay st...@mrclay.org:
On 3/6/13 4:10 PM, Bob Weinand wrote:
https://wiki.php.net/rfc/unset_bool
What's the return value of unset($setValue
Am 06.03.2013 um 22:47 schrieb Ferenc Kovacs tyr...@gmail.com:
On Wed, Mar 6, 2013 at 10:41 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 06.03.2013 um 22:38 schrieb Ferenc Kovacs tyr...@gmail.com:
On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi
Am 6.3.2013 um 22:50 schrieb Will Fitch willfi...@php.net:
On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 06.03.2013 um 22:39 schrieb Will Fitch willfi...@php.net:
On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi!
As this seem
Am 6.3.2013 um 23:30 schrieb Will Fitch wfi...@meetme.com:
On Wed, Mar 6, 2013 at 5:25 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 6.3.2013 um 22:50 schrieb Will Fitch willfi...@php.net:
On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 06.03.2013 um 22:39 schrieb
construct with an __unset
method. (success or failure)
I've added a code example to the RFC.
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
begin to introduce these well-known design patterns there may appear some
sense...
Unset returns false if there was nothing to unset or if an
unset_dimension/property handler has returned false. Short: It doesn't return
true if nothing was successfully unset.
Bob Weinand
which is faster than the
extensions
which always serialize? (or as a new extension… but I really like the proposal
to do like
shared $var; which is (nearly) impossible as an extension)
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
Am 14.3.2013 um 18:14 schrieb Rasmus Lerdorf ras...@lerdorf.com:
On 03/14/2013 09:13 AM, Bob Weinand wrote:
And there is no possibility to store the zval as raw binary data like in
memory (deep copy?)
So that you only have to copy from ram? And replace the pointers to the
place
of arguments?
For instance, the common piece of a hook system implementation, where
the arguments of the functions called vary depending on the hook.
call_user_func is not call_user_func_array
call_user_func($func) is the same as $func(). In any way.
Bob Weinand
--
PHP Internals - PHP
there alone in the combination with
call_user_func_array.
Bob Weinand
would have to
choose I would prefer the parenthesis...)
Bob Weinand
p.s.: I'm wondering why, with this little patch, (function () { print a;
})(); is throwing a fatal error telling me a function name must be a string
while ($temp = function () { print a; })(); is working perfectly?! (I think
I propose to add, contrary to the mysqli::bind_param method which accepts
parameters only by ref (and triggers a fatal error when passing non-ref
variables or values), a mysqli::bind_value method which accepts the variables
by value.
There are a few problems when using bind_param which
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com wrote:
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if
Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com wrote:
If you do user_error('whatever
Am 7.5.2013 um 21:49 schrieb Sebastian Krebs krebs@gmail.com:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com
Am 7.5.2013 um 22:11 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error
originates from. You debug today trigger_error's in libraries with
putting a
FLAG_B = 2;
const FLAG_C = 4;
With this proposal we would write:
function func ($arg = 1 | 2 | 4) # we now need to lookup first which constants
have values 1, 2 and 4
But it would be much more understandable if we were able to write:
function func ($arg = FLAG_A | FLAG_B | FLAG_C)
Bob Weinand
);
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
}
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
Am 31.8.2013 um 01:39 schrieb Lazare Inepologlou linep...@gmail.com:
2013/8/31 Bob Weinand bobw...@hotmail.com
Hi!
Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou linep...@gmail.com:
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
don't see a reason why one should explicitly
= value);
You can find the patch here:
https://github.com/php/php-src/pull/438
Any thoughts about this?
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 12.9.2013 um 09:10 schrieb Michael Wallner m...@php.net:
On 11 September 2013 23:21, Bob Weinand bobw...@hotmail.com wrote:
Hi!
I tried to widen the naming possibilities by allowing to use keywords as
identifiers (for function names, class names, label (goto) names, ...) where
Am 12.9.2013 um 15:06 schrieb Michael Wallner m...@php.net:
On 12 September 2013 14:56, Bob Weinand bobw...@hotmail.com wrote:
A little benchmark here: https://gist.github.com/bwoebi/6536824
Here I picked always the best from 10 times running.
With patch:
root# ./sapi/cli/php
@pierrejoye | http://www.libgd.org
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 12.9.2013 um 22:44 schrieb Johannes Schlüter johan...@schlueters.de:
On Wed, 2013-09-11 at 23:21 +0200, Bob Weinand wrote:
Hi!
I tried to widen the naming possibilities by allowing to use keywords
as identifiers (for function names, class names, label (goto)
names, ...) where possible
Am 13.9.2013 um 11:48 schrieb Johannes Schlüter johan...@schlueters.de:
On Fri, 2013-09-13 at 01:24 +0200, Bob Weinand wrote:
Here is a concrete list when keywords are allowed:
https://github.com/php/php-src/pull/438
Then you should have a better idea what exactly will be allowed in future
. Consider label
else:
Jakub
else::constant; doesn't work too. that's why I've put goto-labels in the same
category like classes etc.
See also: https://github.com/php/php-src/pull/438
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Am 13.9.2013 um 15:31 schrieb Johannes Schlüter johan...@schlueters.de:
On Fri, 2013-09-13 at 14:39 +0200, Bob Weinand wrote:
Am 13.9.2013 um 11:48 schrieb Johannes Schlüter johan...@schlueters.de:
On Fri, 2013-09-13 at 01:24 +0200, Bob Weinand wrote:
Here is a concrete list when keywords
Am 13.9.2013 um 16:18 schrieb Bob Weinand bobw...@hotmail.com:
What then would be still supported exactly is
with the restricted list:
- typehint
- class/trait/interface names
- goto-label
unrestricted:
- method names
- constant names
- property names
- trait aliases
- declare list
Am 14.9.2013 um 23:21 schrieb Pierre Joye pierre@gmail.com:
Hi,
On Sep 14, 2013 10:56 AM, Bob Weinand bobw...@hotmail.com wrote:
Am 13.9.2013 um 16:18 schrieb Bob Weinand bobw...@hotmail.com:
What then would be still supported exactly is
with the restricted list:
- typehint
Am 14.09.2013 um 23:21 schrieb Pierre Joye pierre@gmail.com:
I think we need a RFC for this non trivial change (from a user land point
of view and to change the engine). Do you know how to proceed to create one?
I now created the RFC:
https://wiki.php.net/rfc/keywords_as_identifiers
Bob
Hi!
This is the (official) RFC thread for the patch proposed in
http://php.markmail.org/message/7rn4mbwkbytqa3ig
https://wiki.php.net/rfc/keywords_as_identifiers
Any feedback about the RFC or the implementation?
Bob Weinand
.
You could also argue that the current $obj-default; (that's already possible)
is also bad.
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
was effectively missing a few concrete
examples.
I now added some examples.
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
suggestions.
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(...$args) {
return count($args) == count(array_filter(is_int, $args));
}
So: tl;dr: only in favour if technically not too complicated and doesn't have
the restrictions of
a typical language construct. Else: -1.
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
on older versions. (yes, you CAN change the hoster if
he
doesn't provide the newest PHP version, or (when you have the rights to) just
upgrade
it yourself.)
This is really a non-argument.
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
Am 18.09.2013 um 21:57 schrieb Leigh lei...@gmail.com:
On 18 September 2013 18:50, Bob Weinand bobw...@hotmail.com wrote:
At least, from a technical point, evaluating LTR would require to change the
engine
(would be some more complex change as it would require to switch between
contexts
misunderstood what you meant.
Then the idea is acceptable. Not sure if we need this as it is very easily
possible with an one-liner in userspace code.
I'm +- 0 on this.
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 16.10.2013 um 23:53 schrieb Bob Weinand bobw...@hotmail.com:
Am 16.9.2013 um 14:53 schrieb Bob Weinand bobw...@hotmail.com:
Hi!
This is the (official) RFC thread for the patch proposed in
http://php.markmail.org/message/7rn4mbwkbytqa3ig
https://wiki.php.net/rfc
Hey Dmitry,
I wonder why you pushed that before having any vote on the
https://wiki.php.net/rfc/fast_zpp RFC?
Please revert this until we've voted there.
Thank you,
Bob
Am 11.7.2014 um 18:54 schrieb Pierre Joye pierre@gmail.com:
hi Dmitry,
And now I wonder why you even bother to
Am 21.7.2014 um 12:52 schrieb Pierre Joye pierre@gmail.com:
On Mon, Jul 21, 2014 at 11:50 AM, Dmitry Saprykin
saprykin.dmi...@gmail.com wrote:
Ok, I will NOT ))
God saves us from bureaucracy
Well, Michael's view is known.
However let me explain what RFCs bring, besides bureaucracy.
:(
I'll try to think about it later today.
Could you please collect all related issues.
Thanks. Dmitry.
On Mon, Jul 21, 2014 at 8:36 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 2.7.2014 um 15:43 schrieb Dmitry Stogov dmi...@zend.com:
I don't have good ideas out of the box and I
it helps…
I don't even remember why I even added that restriction there.
Bob
Am 23.7.2014 um 10:47 schrieb Dmitry Stogov dmi...@zend.com:
On Wed, Jul 23, 2014 at 12:16 PM, Bob Weinand bobw...@hotmail.com wrote:
Hey, thank you for looking into it :-)
Am 23.7.2014 um 00:23 schrieb Dmitry Stogov
Am 23.7.2014 um 11:34 schrieb Dmitry Stogov dmi...@zend.com:
On Wed, Jul 23, 2014 at 1:20 PM, Bob Weinand bobw...@hotmail.com wrote:
Yes. Did you see my thoughts before?
I'm just wondering if we can't somehow deeply copy the asts for opcache
between compile time and run time in pass_two
Am 23.7.2014 um 22:33 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
It was a restriction to not support arrays in constant context. It seems
like nobody can remember why it was introduced.
My vague recollection is that it had some troubles with keeping
refcounts consistent, esp.
Am 27.7.2014 um 10:55 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
Yes, I agree that this is not correct behavior - and I don't really
understand why it was introduced and why it isn't trivial to fix.
PHP-5.5 had a check for this case in place
Am 28.7.2014 um 15:03 schrieb Matteo Beccati p...@beccati.com:
Hi everyone,
On 28/07/2014 09:46, Michael Wallner wrote:
https://bugs.php.net/patch-display.php?bug=67064patch=bug67064-BCrevision=1402667581
+1 on Matteo's patch. Rather a single fix than a couple.
IIRC, we also have to think
Am 30.7.2014 um 17:08 schrieb Ferenc Kovacs tyr...@gmail.com:
On Wed, Jul 30, 2014 at 4:48 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Wed, Jul 30, 2014 at 3:54 PM, Matteo Beccati p...@beccati.com wrote:
Hi Bob,
On 30/07/2014 14:33, Bob Weinand wrote:
Is this a problem if the interface
Am 19.8.2014 um 00:09 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
Since we've had phpng branch merged to master the build on Travis CI is
broken for master (as in, doesn't even build). Could it be fixed? It's
not a good thing that we have master branch that CI can not even run on.
I
Am 22.8.2014 um 13:16 schrieb Nikita Popov nikita@gmail.com:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which
After a long time… back to our fast_zpp RFC.
Initially Dmitry proposed to have two different APIs, one for the fast version,
one for current version:
#if FAST_ZPP
/* new API */
#else
/* old style zend_parse_parameters API */
#endif
I don't really like the idea of having two different
https://bugs.php.net/bug.php?id=68057
is a regression introduced in PHP 5.6.
So code which still worked with PHP 5.5 breaks in 5.6.
The big issue is here, that the fix for this bug requires ABI breakage.
(changing an unsigned short into a zend_uint)
I know that ABI compatibility is a pretty
I know we have that already discussed a lot now, but I’d like to expose my
points on the return value here:
I imagine code like (supposing that we ever will have scalar typehints):
function acceptsInt (int $i = null) {
if ($i === null) {
$i = 2 /* default value */;
}
/* do
Am 25.10.2014 um 13:25 schrieb Leigh lei...@gmail.com:
On 25 October 2014 12:00, Weinand Bob bobw...@hotmail.com wrote:
...
Thanks Bob.
So my question is: Obviously the phpdbg requirements do not map to
DBGp. However, can all of the requirements of DBGp be mapped to the
phpdbg XML?
Am 26.10.2014 um 12:58 schrieb Pierre Joye pierre@gmail.com:
On Sun, Oct 26, 2014 at 3:24 AM, Joe Watkins pthre...@pthreads.org wrote:
I'd like to everyone to stay grounded in reality and say that we have
been checking code into php-src for months, very very few people have
expressed
Am 26.10.2014 um 16:17 schrieb Derick Rethans der...@php.net:
On Sat, 25 Oct 2014, Weinand Bob wrote:
Just a minor question, Derick. If you care about phpdbg, why are you
only dropping any comment about it by the time it got into php-src
repo?
Yes, my mistake. I should have voted -1,
Am 26.10.2014 um 16:22 schrieb Derick Rethans der...@php.net:
On Sat, 25 Oct 2014, Joe Watkins wrote:
We will notify internals of our intentions to make such changes in
future, if we thought there was any chance of any feedback before today,
we would already be doing so.
We will notify
Am 26.10.2014 um 16:26 schrieb Derick Rethans der...@php.net:
On Sun, 26 Oct 2014, Andrea Faulds wrote:
On 26 Oct 2014, at 15:09, Derick Rethans der...@php.net wrote:
On Sat, 25 Oct 2014, Joe Watkins wrote:
On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote:
A few weeks ago,
Am 26.10.2014 um 16:09 schrieb Derick Rethans der...@php.net:
On Sat, 25 Oct 2014, Joe Watkins wrote:
On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote:
On Fri, 24 Oct 2014, Bob Weinand wrote:
Commit:2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Author:Bob Weinand bobw
Am 26.10.2014 um 17:23 schrieb Lester Caine les...@lsces.co.uk:
On 26/10/14 15:41, Bob Weinand wrote:
Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
They just initially requested it because they didn’t knew any better
protocol. That’s all.
PHPStorm like PHP-FIG
probably redirect
phpdbg.com http://phpdbg.com/ page to php.net http://php.net/.
The phpdbg.com http://phpdbg.com/ page is currently just horribly outdated
and a relict from that time before phpdbg was merged into php-src.
Bob Weinand
Hey, I can accept that.
But it’d be great if you could only revert now in the 5.6.3 release branch, not
in the 5.6 development branch, so that this gives us now still some time to see
what exactly we want to revert or not and for some eventual RFC?
To add for 3.: Issues where with what I
Am 30.10.2014 um 13:06 schrieb Ferenc Kovacs tyr...@gmail.com:
On Thu, Oct 30, 2014 at 11:59 AM, Bob Weinand bobw...@hotmail.com
mailto:bobw...@hotmail.com wrote:
Hey, I can accept that.
But it’d be great if you could only revert now in the 5.6.3 release branch,
not in the 5.6
Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/ http://www.sugarcrm.com/
---
Bob Weinand
Am 03.11.2014 um 22:03 schrieb Derick Rethans der...@php.net:
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,
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
As announced yesterday, I put the RFC into vote now.
Voting period is 8 days, it will end 24th of February.
The RFC is here:
https://wiki.php.net/rfc/date.timezone_warning_removal
https://wiki.php.net/rfc/date.timezone_warning_removal
I also slightly reworded the feedback section in reply to
I'd like to show you my recent work on a jumptable optimization for switches.
https://github.com/php/php-src/pull/1048
https://github.com/php/php-src/pull/1048
It is a fully transparent optimization of switches, by putting a new
ZEND_SWITCH opcode at the top of the switch in case we can build
Am 17.02.2015 um 00:30 schrieb Rasmus Lerdorf ras...@lerdorf.com:
On 02/16/2015 03:04 PM, Bob Weinand wrote:
I'd like to show you my recent work on a jumptable optimization for switches.
https://github.com/php/php-src/pull/1048
https://github.com/php/php-src/pull/1048
It is a fully
Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com:
On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
During the PHP 5.6 development cycle I have proposed an RFC [1] that
suggested the use of exceptions instead of fatal errors in the
Am 17.02.2015 um 11:21 schrieb Benjamin Eberlei kont...@beberlei.de:
On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand bobw...@hotmail.com
mailto:bobw...@hotmail.com wrote:
Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com
mailto:nikita@gmail.com:
On Mon, Oct 6, 2014
Am 27.01.2015 um 12:49 schrieb Matteo Beccati p...@beccati.com:
On 27/01/2015 12:28, Nikita Popov wrote:
So let the distros solve it ... and allow PHP to still be usable without an
ini file.
So, I install php from sources and (simulating the RFC):
# php -d date.timezone='' -r
Am 27.01.2015 um 16:27 schrieb Matteo Beccati p...@beccati.com:
On 27/01/2015 15:12, Bob Weinand wrote:
If you use the distros default, it often is UTC too. Then we have
this same issue, just without warning. This warning often doesn't
help at all, because it just doesn't appear at all
Hey,
I'd like to request removal of the date.timezone warning.
Here is the RFC:
https://wiki.php.net/rfc/date.timezone_warning_removal
https://wiki.php.net/rfc/date.timezone_warning_removal
Bob
I'm probably going to put this into vote tomorrow.
The RFC got some update from neutrality aspect and covers some feedback from
the initial discussion thread.
The link is:
https://wiki.php.net/rfc/date.timezone_warning_removal
https://wiki.php.net/rfc/date.timezone_warning_removal
Bob
Am 14.03.2015 um 00:44 schrieb Zeev Suraski z...@zend.com:
Zeev,
If I put it into vote until Sunday, we're breaking the voting process.
Which
required an apt discussion phase which definitely isn't given when we
start
Sunday.
Bob,
I do see it differently but obviously very much
Hey, to clarify what the way to go with this RFC is.
This RFC is a FALLBACK. It's about the common part of both other RFCs.
That way it *only* will go to vote after Anthonys RFC ends. And *only* if it
fails.
That means, I will go by the voting RFC and wait until discussion period ends
and put
.
Zeev
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Sunday, March 15, 2015 5:51 PM
To: PHP Internals
Subject: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
Hey, to clarify what the way to go with this RFC is.
This RFC is a FALLBACK. It's about the common
Am 15.03.2015 um 18:48 schrieb Anthony Ferrara ircmax...@gmail.com:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be
consistent with our existing type hints for classes, callables and arrays,
NULL is not accepted by default,
Am 09.03.2015 um 12:04 schrieb David Zuelke d...@heroku.com:
Why not wait with the merge until a consensus emerges regarding Throwable?
On 09.03.2015, at 05:26, Nikita Popov nikita@gmail.com wrote:
On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov nikita@gmail.com wrote:
Hi
Am 09.03.2015 um 11:24 schrieb Derick Rethans der...@php.net:
On Fri, 27 Feb 2015, Xinchen Hui wrote:
Hey Internals:
I was looking Bob's switch optimization..
then I start to worry about where is the place optimization should
goes..
in generally, PHP is a
Hi all,
after all, some people are not happy with the current proposals about scalar
types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals fail:
https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future
Am 11.03.2015 um 23:29 schrieb Pavel Kouřil pajou...@gmail.com:
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.
Besides what I think of proposing yet another RFC, -1 because it is
basically what the initial idea from the opponents of
Am 13.03.2015 um 23:03 schrieb Zeev Suraski z...@zend.com:
Maybe I was naïve, but I thought I had a better way to make both weak
strict camps happy, instead of just ignoring the strict camp altogether.
While there was some opposition to it - it mostly came from the main
proponents of the
Am 14.03.2015 um 00:14 schrieb Zeev Suraski z...@zend.com:
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski; guilhermebla...@gmail.com
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
Am 13.03.2015 um 05:01 schrieb Xinchen Hui larue...@php.net:
Hey:
We have CALL SWITCH GOTO vm kind supports for long time.
And we use CALL for default.
SWITCH GOTO seems useless now, and brings us some troubles while
maintaining .
And also could make some extension
1 - 100 of 296 matches
Mail list logo
