Am 28.08.2013 21:27, schrieb Matthew Leverton:
On Wed, Aug 28, 2013 at 10:47 AM, Nikita Popov nikita@gmail.com wrote:
snip
Would any functions get deprecated as a result of this? e.g., func_get_args()
snip
It's not a good idea to deprecate the function
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.
The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP
...
// changed functions (added
Am 29.08.2013 14:00, schrieb Ángel González:
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.
The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const
Am 30.08.2013 04:30, schrieb Yasuo Ohgaki:
On Thu, Aug 29, 2013 at 9:00 PM, Ángel González keis...@gmail.com wrote:
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.
The following psaudocode is self explained
modules like openssl/gmp it should be possible to add there
own algorithm that can be used with the same simple API.
Bryan
-Original Message-
From: Marc Bennewitz [mailto:p...@marc-bennewitz.de]
Sent: Friday, August 30, 2013 2:59 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV
Am 01.09.2013 15:12, schrieb Jakub Zelenka:
The whole proposal is a bit confusing for me. The combination of PRNG
algorithm (MT) with libraries (libc, OpenSSL, GMP) that implements one or
more PRNG algorithms just doesn't make sense to me. It doesn't say anything
about the speed and crypto
Am 02.10.2013 20:38, schrieb Adam Harvey:
On 2 October 2013 10:57, Christopher Jones christopher.jo...@oracle.com
wrote:
On 10/02/2013 10:26 AM, Nikita Popov wrote:
I'd like to change our double-to-string casting behavior to be
locale-independent and would appreciate some opinions as to
Hi Yasuo,
Some times ago I mailed my idea about refactoring random number
generator API with min BC breaks but I didn't create an RFC right now.
see http://marc.info/?l=php-internalsm=137772363015217
Marc
On 16.07.2014 07:13, Yasuo Ohgaki wrote:
Hi all,
There are few places that uses
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned integers from/to PHP using the
un/pack functions
- simplified right
Hi all,
I have a new email address ending @mabe.berlin but I can't confirm
this in the ML :(
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned integers from/to PHP using the
un/pack functions
- simplified right
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned integers from/to PHP using the
un/pack functions
- simplified right
ups (typo + copy past error)
It's not my day today!
On 22.07.2014 22:21, Rowan Collins wrote:
On 22/07/2014 20:55, Marc Bennewitz wrote:
I like to create an RFC to add an unsinged integer type
+1 for not turning the iron up too high when doing your maths!
[https://en.wiktionary.org/wiki
I mean a new scalar type here
On 22.07.2014 22:33, Nikita Popov wrote:
On Tue, Jul 22, 2014 at 9:55 PM, Marc Bennewitz p...@marc-bennewitz.de
wrote:
Hi all,
I like to create an RFC to add an unsigned integer type for the
following purposes:
- higher max value
- DBs already allow
Hi Andrea,
very nice RFC!
You have added the new type internally only. Does it make sense or would
it be possible to use one more internal type like ULONG to safe
mem/cpu in such cases because bigint/GMP objects are used only on much
higher numbers?
Marc
On 23.07.2014 00:12, Andrea Faulds
Hi internals,
I have opened a PR in april but since that there is no process on it.
Please tell me if there are open questions / todos.
https://github.com/php/php-src/pull/659
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi internals,
I have created a PR to improve the base 2 and base 10 of the standard
math function log to reduce rounding errors.
Internally on log(x, 2) the native C function log2(x) and on log(x, 10)
the native C function log10(x) will be called.
The PR is open since april without any
forgotten the link:
https://github.com/php/php-src/pull/658
On 14.08.2014 11:43, Marc Bennewitz wrote:
Hi internals,
I have created a PR to improve the base 2 and base 10 of the standard
math function log to reduce rounding errors.
Internally on log(x, 2) the native C function log2(x
On 14.08.2014 17:29, Sara Golemon wrote:
On Thu, Aug 14, 2014 at 2:44 AM, Marc Bennewitz php@mabe.berlin wrote:
forgotten the link:
https://github.com/php/php-src/pull/658
On 14.08.2014 11:43, Marc Bennewitz wrote:
Hi internals,
I have created a PR to improve the base 2 and base 10
Sara,
shouldn't it be merged into the branches PHP-5.4, PHP-5.5 as well as
PHP-5.6 and shouldn't there an info in the NEWS file? It's currently
only merged to master.
Marc
On 14.08.2014 17:29, Sara Golemon wrote:
On Thu, Aug 14, 2014 at 2:44 AM, Marc Bennewitz php@mabe.berlin wrote:
forgotten
On 15.08.2014 22:39, Andrea Faulds wrote:
On 15 Aug 2014, at 19:57, Marc Bennewitz php@mabe.berlin wrote:
Sara,
shouldn't it be merged into the branches PHP-5.4, PHP-5.5 as well as
PHP-5.6 and shouldn't there an info in the NEWS file? It's currently
only merged to master.
Marc
On 15.08.2014 22:39, Andrea Faulds wrote:
On 15 Aug 2014, at 19:57, Marc Bennewitz php@mabe.berlin wrote:
Sara,
shouldn't it be merged into the branches PHP-5.4, PHP-5.5 as well as
PHP-5.6 and shouldn't there an info in the NEWS file? It's currently
only merged to master.
Marc
Hi internals!
I've created a draft RFC and patch to change the behavior of non-strict
string to string comparison to be binary safe (as the strict comparison
operator does):
https://wiki.php.net/rfc/binary_string_comparison
On comparing two numeric strings both operands will be equal
On 17.08.2014 22:18, Sara Golemon wrote:
On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz php@mabe.berlin wrote:
I've created a draft RFC and patch to change the behavior of non-strict
string to string comparison to be binary safe (as the strict comparison
operator does):
https
On 18.08.2014 14:53, Pierre Joye wrote:
hi,
On Mon, Aug 18, 2014 at 2:44 PM, Marc Bennewitz php@mabe.berlin wrote:
On 17.08.2014 22:18, Sara Golemon wrote:
On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz php@mabe.berlin wrote:
I've created a draft RFC and patch to change the behavior
On 18.08.2014 17:43, Johannes Schlüter wrote:
On Mon, 2014-08-18 at 17:30 +0200, Johannes Schlüter wrote:
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
...@schlueters.de mailto:johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
The question isn't What's wrong with ===, strcmp()? but
What's wrong
with ==, , ?.
We have a standard way to compare two operands but currently
we do
On 20.08.2014 12:46, Michael Wallner wrote:
On 20/08/14 11:12, Marc Bennewitz wrote:
On 18.08.2014 17:43, Johannes Schlüter wrote:
On Mon, 2014-08-18 at 17:30 +0200, Johannes Schlüter wrote:
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd
On 20.08.2014 19:50, Ferenc Kovacs wrote:
2014.08.17. 21:59 ezt írta (Marc Bennewitz php@mabe.berlin):
Hi internals!
I've created a draft RFC and patch to change the behavior of
non-strict string to string comparison to be binary safe (as the strict
comparison operator does
On 19.08.2014 00:41, Stas Malyshev wrote:
Hi!
I opted for master-only on the grounds that while it's an improvement,
it's not really a bugfix, and released versions (or versions as near
to release as 5.6 is) should be bug-fix only. I know there's an
argument for this *being* a bug-fix,
On 21.08.2014 17:30, Derick Rethans wrote:
On Tue, 19 Aug 2014, Kris Craig kris.cr...@gmail.com wrote:
On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote:
I have made an RFC which would make some small changes to how integers
are handled, targeted at PHP 7:
On 13.10.2014 02:45, Marco Pivetta wrote:
On 12 October 2014 00:47, Andrea Faulds a...@ajf.me wrote:
On 11 Oct 2014, at 23:42, Rowan Collins rowan.coll...@gmail.com wrote:
func_get_args() and func_num_args(), OTOH, existed solely to support
variadics, and anything taking advantage of them
On 13.10.2014 20:48, Marco Pivetta wrote:
On 13 October 2014 20:20, Marc Bennewitz php@mabe.berlin
mailto:php@mabe.berlin wrote:
On 13.10.2014 02:45, Marco Pivetta wrote:
Your implementation of userland_call_user_func doesn't have the same
visibility as call_user_func[_array
On 13.10.2014 22:26, Marco Pivetta wrote:
On 13 October 2014 21:18, Marc Bennewitz php@mabe.berlin
mailto:php@mabe.berlin wrote:
On 13.10.2014 20:48, Marco Pivetta wrote:
On 13 October 2014 20:20, Marc Bennewitz php@mabe.berlin
mailto:php@mabe.berlin wrote
... like the hidden array element: http://3v4l.org/6uFqf
... like the hidden object property: http://3v4l.org/RPJXH
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 14.10.2014 09:25, Stas Malyshev wrote:
Hi!
... like the hidden array element: http://3v4l.org/6uFqf
... like the hidden object property: http://3v4l.org/RPJXH
The issue seems to be that array lookup always looks for numeric results
when looking for numeric-like keys. But when adding
On 22.10.2014 10:37, Bob Weinand wrote:
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 really like the strictness of this casting rules except of 010 will
be a valid integer / float.
As of you don't allow 0x and trailing white spaces as valid numbers
and don't allow floating like syntax as integers even if it result in
mathematical integer.
Allowing prefixed 0 as valid numbers
You addresses data loss on convert float to int.
Do you also address data loss on int to float?
|to_float(||9223372036854774784) - pass |as it results in
9223372036854774784
|to_float(|||9223372036854774785|) - |failas it results in
9223372036854774784
|
Marc
|
On 23.10.2014 21:40, Marc
On 24.10.2014 01:53, Andrea Faulds wrote:
On 23 Oct 2014, at 20:50, Marc Bennewitz php@mabe.berlin wrote:
You addresses data loss on convert float to int.
Do you also address data loss on int to float?
|to_float(||9223372036854774784) - pass |as it results in
9223372036854774784
|to_float
On 24.10.2014 20:13, Andrea Faulds wrote:
On 24 Oct 2014, at 19:06, Marc Bennewitz php@mabe.berlin wrote:
On 24.10.2014 01:53, Andrea Faulds wrote:
On 23 Oct 2014, at 20:50, Marc Bennewitz php@mabe.berlin wrote:
You addresses data loss on convert float to int.
Do you also address data
On 24.10.2014 20:54, Andrea Faulds wrote:
On 24 Oct 2014, at 19:52, Marc Bennewitz php@mabe.berlin wrote:
Floats are special, they are not expected to be precise. If we reject this,
then perhaps we should also reject 0.1, because it can’t be precisely
represented by a float?
It's
On 12.10.2014 12:10, Nikita Popov wrote:
On Sun, Oct 12, 2014 at 10:37 AM, Robert Stoll p...@tutteli.ch wrote:
Hey,
I just stumbled over a method call of a non-static method with self and
was asking myself again, why does PHP support
this behaviour. An example to outline what I am
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of unknown string values:
class MyFactory {
public static function factory($name) : AdapterInterface {
$class =
Hi internals,
In OOP it's a sometimes a common issue to know the state of an object
and to know if it was changed respectively it it can change state.
We already have such objects like DateTImeImmutable and new proposed
objects like UString also introduce immutable objects.
I think it
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base
Am 25.11.2014 um 23:13 schrieb Marc Bennewitz:
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2)
because
one of the use cases for return type-hint are factories
Thoughts ?
Am 25.11.2014 um 22:26 schrieb Marc Bennewitz:
Hi internals,
In OOP it's a sometimes a common issue to know the state of an object
and to know if it was changed respectively it it can change state.
We already have such objects like DateTImeImmutable and new proposed
objects like
Am 27.11.2014 um 20:47 schrieb Levi Morrison:
Am 25.11.2014 um 22:26 schrieb Marc Bennewitz:
Hi internals,
In OOP it's a sometimes a common issue to know the state of an object and
to know if it was changed respectively it it can change state.
We already have such objects like
Please read :
http://grokbase.com/t/php/php-internals/14acs23cpe/disallow-non-static-method-calls-with-self-static-in-php-7#20141026ct1np9k82bte2m9k9rtmq1c2jr
Am 28.11.2014 um 20:29 schrieb Carlos Rodrigues:
PHP has evolved a lot in recent years but we still can't have a static and
a
Am 28.11.2014 um 21:21 schrieb Levi Morrison:
Won't `$obj1 === $obj2` work for you ?
This works if you have two objects which are easily accessible in the same
scope.
Not that it can not be done this way, but it may require jumping through
hoops to get two object references into the common
Hi all,
Is it possible to make a zval persistent?
Currently I only found persistent resources or internal references used
in objects.
It would be very great for some userland applications to make a value
persistent whatever type it is.
Like the internal global persistent_list but this one
Am 09.12.2014 um 20:03 schrieb Sara Golemon:
On Tue, Dec 9, 2014 at 10:58 AM, Marc Bennewitz dev@mabe.berlin wrote:
Is it possible to make a zval persistent?
Nope.
Why?
There is a reference counter, which should be increased on put a value
into persistence and on removing a value from
Am 10.12.2014 um 09:53 schrieb Stanislav Malyshev:
Hi!
Why?
There is a reference counter, which should be increased on put a value
into persistence and on removing a value from persistence decrease it.
So the GC could handle unreferenced zvals.
Because memory which is allocated by the
Hi all,
Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can
define binary strings but such definitions haven't any effect.
So what we can define is the following:
$str = str;
$bin = bb\0i\0n;
$str2bin = (binary)$str;
One of the biggest issue is that currently ALL strings
Am 14.01.2015 um 20:21 schrieb Adam Harvey:
On 14 January 2015 at 11:15, Marc Bennewitz dev@mabe.berlin wrote:
But I think adding default as new keyword is a big BC break!
Default already is a keyword: http://php.net/switch. There's no BC break.
OMG you are right - my fault
I personally
Hi Andrea,
I have some notes about this RFC from a users POV with only little
knowledge about internals.
I didn't read 100% of the theads of this RFC so I'm sorry if some notes
of this email was already discussed.
1. Inconsistencies of ZPP and explicit casts
In my opinion it should be the
Hi Stas,
I really like this RFC. It makes it simple to use defined defaults
without the need to know about them of to updated.
But I think adding default as new keyword is a big BC break!
I personally also don't like it and asked myself why can't the parameter
simply skipped?
function
Am 15.01.2015 um 20:45 schrieb Marcio Almada:
Hi,
I would like to call everyone's attention, specially people
contributing directly to this RFC series, to what S.A.N just said:
Many developers PHP offers dual syntax:
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
Am 14.01.2015 um 23:39 schrieb Andrea Faulds:
Hi Marc,
On 14 Jan 2015, at 19:01, Marc Bennewitz dev@mabe.berlin wrote:
1. Inconsistencies of ZPP and explicit casts
In my opinion it should be the same if you call a function in weak type mode
and calling a function in strict type mode
Hi Robert
Am 16.01.2015 um 11:04 schrieb Robert Stoll:
Hi Stas,
-Ursprüngliche Nachricht-
Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
Gesendet: Mittwoch, 14. Januar 2015 21:26
An: Marc Bennewitz; internals@lists.php.net
Betreff: Re: [PHP-DEV] [RFC] Skipping parameters take 2
Am 20.01.2015 um 18:58 schrieb Levi Morrison:
Internals,
Last year I fixed the behavior of closures in a few regards, which
were included in PHP 5.5.14 and 5.6 (unsure on exact version):
- Static closures properly use late-static binding on `static::`
calls from inside static methods.
-
Am 19.01.2015 um 19:48 schrieb Adam Harvey:
On 17 January 2015 at 18:04, Andrea Faulds a...@ajf.me wrote:
For consistency with list(), we could also just put nothing:
foo($bar, , $baz);
Which is like:
list($bar, , $baz) = $arr;
Thoughts?
That was Stas's original, original
On 20.01.2015 22:46, Nikita Popov wrote:
On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin wrote:
valid for call_user_func[_array] and callable type-hint but invalid
for for direct variable calls:
- string MyClass::staticFunc
- string self
valid for call_user_func[_array] and callable type-hint but invalid for
for direct variable calls:
- string MyClass::staticFunc
- string self::staticFunc
- string static::staticFunc
- string parent::func
- string parent::staticFunc
see http://3v4l.org/1oSO3
Thoughts ?
--
PHP Internals - PHP
Hi Stas,
Am 12.02.2015 um 22:31 schrieb Stanislav Malyshev:
Hi!
class A {
// This is an *instance* method, but it doesn't actually use $this.
// This kind of usage is very common in PHP 4 era code, where
// static annotations weren't used
function test() {
echo
Hi
Am 13.02.2015 um 08:48 schrieb Stanislav Malyshev:
Hi!
there should be no bc break as the API doesn't change and the method
produces the exact same result as before.
Sorry, this makes no sense to me. You claim that if you changed the
method code to do different thing it should continue
Am 20.03.2015 um 09:03 schrieb Wei Dai:
Hi internals,
Hi internals,
The RFC to add a user-land function for an easy-to-use and reliable
preg_replace_callback_array() in PHP is up for discussion:
https://wiki.php.net/rfc/preg_replace_callback_array
This proposes adding one function:
I also had a question! Didn't you noticed it?
Am 20.03.2015 um 16:49 schrieb Marc Bennewitz:
Why not simply allow the callback to be an array, too?
Marc
Am 21.03.2015 um 09:14 schrieb Xinchen Hui:
Hey:
On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui larue...@php.net wrote:
Hey:
On Fri, Mar
Am 30.03.2015 um 12:58 schrieb Thomas Punt:
Hey,
Imho TypeException may not be best name for
it, as it's also thrown for non-type related error conditions, like
mismatched argument count.
Would SignatureException be a more apt name for these error conditions?
We already have an
Am 01.03.2015 um 20:04 schrieb Dan Ackroyd:
On 1 March 2015 at 18:35, Marc Bennewitz dev@mabe.berlin wrote:
What are the reasons to not make this class instantiable / extendable ?
That class handles database state / resources that are not exposed
through the userland classes. It's correct
Hi Dan,
Am 01.03.2015 um 15:55 schrieb Dan Ackroyd:
Hi Internals,
This email is to announce the formal opening of discussion for an RFC
to clean up the behaviour of the constructors shown by several
internal classes.
https://wiki.php.net/rfc/internal_constructor_behaviour
I really like this
Hi all,
Because the feature freeze for PHP 7 is near I like to know your
thoughts about one more change in passing arguments. Sure this one would
introduce one more deprecated message / BC break but this one s for
reducing BC break in the future!
Currently a caller can pass undefined
Hi Dimitry,
Am 19.02.2015 um 16:13 schrieb Dmitry Stogov:
Hi Nikita,
I refactored your implementation: https://github.com/php/php-src/pull/1095
I introduced a class hierarchy to minimize effect on existing code.
cacth (Exception $e) won't catch new types of exceptions.
BaseException
Hi Marcio,
Am 23.02.2015 um 21:15 schrieb Marcio Almada:
2015-02-23 16:32 GMT-03:00 Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin:
Hi all,
Because the feature freeze for PHP 7 is near I like to know your
thoughts about one more change in passing arguments. Sure this one
Am 30.04.2015 um 14:30 schrieb Julien Pauli:
On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann sebast...@php.net
wrote:
Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev:
I like the idea, however we do have the deadline and the
deadline has been passed. So I wonder if we can't keep it for
Hi Nikita, Dmitry,
I think it's a mistake to throw a TypeException on invalid argument
count as in this case it has nothing to do with a type.
Marc
Am 03.04.2015 um 20:48 schrieb Dmitry Stogov:
I don' t see any problems.
Thanks. Dmitry.
On Fri, Apr 3, 2015 at 6:31 PM, Nikita Popov
Am 04.04.2015 um 00:13 schrieb Andrea Faulds:
On 3 Apr 2015, at 23:08, Dmitry Stogov dmi...@zend.com wrote:
On Apr 4, 2015 12:34 AM, Nikita Popov nikita@gmail.com wrote:
Don't think we need to disable compile-time evaluation for 2) and 3). It'll
just end up being a compile error in that
Am 01.04.2015 um 18:15 schrieb Dan Ackroyd:
Hi,
I'd like to get people's feedback for the idea of making setlocale be
either deprecated and to be removed eventually or just increasing the
warning level against people using it.
What if the system is configured with a different locale?
OK we
Hi internals,
On experimenting with return type-hints I noted an inconsistency on
overwriting an existing hint to a more specific one. On adding a non
existing return type-hint on overwrite it's fine but it's logically the
same (this previously was an E_STRICT).
http://3v4l.org/YdB8s -
Am 01.04.2015 um 20:58 schrieb Stanislav Malyshev:
Hi!
https://bugs.php.net/bug.php?id=67127 - breaks DateTime
This looks like misunderstanding how float-to-string works. If you asked
it to put commas as decimal separator, don't be surprised it puts commas
as decimal separator.
This should
Hi
Am 01.04.2015 um 21:02 schrieb Stanislav Malyshev:
Hi!
- make strtoupper/strtolower etc. to work with ascii only
This would be a bad idea, however much better idea is to make *system*
case folding (i.e. methods, classes, etc.) use ascii-only. Which we
already mostly do (see
Hi Anthony,
Am 01.04.2015 um 21:25 schrieb Anthony Ferrara:
Marc,
On Wed, Apr 1, 2015 at 2:46 PM, Marc Bennewitz dev@mabe.berlin wrote:
Hi internals,
On experimenting with return type-hints I noted an inconsistency on
overwriting an existing hint to a more specific one. On adding a non
On 06/04/2015 10:01 AM, Yasuo Ohgaki wrote:
Hi all,
On Thu, Jun 4, 2015 at 12:07 AM, Sara Golemon poll...@php.net wrote:
On Wed, Jun 3, 2015 at 1:33 AM, Dominic Grostate
codekest...@googlemail.com wrote:
Has there been any discussion or consideration towards migrating or at
least aliasing
On 06/04/2015 06:35 AM, Yasuo Ohgaki wrote:
Hi Brian,
On Thu, Jun 4, 2015 at 7:33 AM, Brian Moon br...@moonspot.net wrote:
This is a better representation of what you are trying to show. It removes
all the magic call back stuff that could be adding to the slowness you are
seeing. In
On 06/25/2015 09:31 PM, Christoph Becker wrote:
Marc Bennewitz wrote:
I would really like to see directly calling a string of Class::method
be fixed for 7.0.
It's currently resulting in a fatal error and is inconsistent with
call_user_func[_array], is_callable and the callable type-hint
On 06/25/2015 09:39 PM, Marc Bennewitz wrote:
On 06/25/2015 09:31 PM, Christoph Becker wrote:
Marc Bennewitz wrote:
I would really like to see directly calling a string of Class::method
be fixed for 7.0.
It's currently resulting in a fatal error and is inconsistent with
call_user_func
On 06/25/2015 05:03 PM, Kalle Sommer Nielsen wrote:
Howdy
This is a quick heads up that we plan to have the next release of
7.0.0 be Beta 1, this marks a feature freeze and from there on, we
will switch focus on to stabilization, regressions and other bug
fixes.
Beta 1 is schedule to be
On 06/28/2015 09:22 PM, Christoph Becker wrote:
Marc Bennewitz wrote:
On 06/25/2015 09:48 PM, Aaron Piotrowski wrote:
On Jun 25, 2015, at 2:39 PM, Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin wrote:
Nice to see this - didn't noted it in the last month :)
But there is one edge
On 06/25/2015 09:48 PM, Aaron Piotrowski wrote:
On Jun 25, 2015, at 2:39 PM, Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin wrote:
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current
behavior;
http://3v4l.org
On 05/23/2015 10:12 PM, Aaron Piotrowski wrote:
Hello, I’ve created an RFC for modifying the exception hierarchy for
PHP 7, adding Throwable interface and renaming the exceptions thrown
from fatal errors. The RFC is now ready for discussion. RFC:
https://wiki.php.net/rfc/throwable-interface
On 05/24/2015 10:11 PM, Aaron Piotrowski wrote:
On May 24, 2015, at 2:08 PM, Marc Bennewitz dev@mabe.berlin wrote:
Where are the new classes and the interface located if it's not in the global
namespace or do I muss something?
Sorry if what I wrote wasn’t clear. Throwable, Error
On 05/24/2015 11:32 PM, Yasuo Ohgaki wrote:
Hi Aaron,
On Sun, May 24, 2015 at 5:12 AM, Aaron Piotrowski aa...@icicle.io wrote:
I’ve created an RFC for modifying the exception hierarchy for PHP 7,
adding Throwable interface and renaming the exceptions thrown from fatal
errors. The RFC is now
Hi,
I have noted that detecting a class name using ::class it will return
the called case instead of the original case.
see http://3v4l.org/97K36
That's annoying as I like to check the right class case on autoload to
detect mistakes.
Sure, class names in PHP are case-insensitive but
Hi Rowan,
On 11/02/2015 05:41 PM, Rowan Collins wrote:
Alexander Lisachenko wrote on 02/11/2015 11:12:
First definition declares exactly one single parameter, which can be
absent during the method call, so I can even write
public static function test() {}
Second definition defines zero or
On 10/15/2015 01:19 AM, Larry Garfield wrote:
On 10/14/2015 06:00 PM, Andrea Faulds wrote: >> Both you and Stas have said this, but it's only true if we solely
>> consider C-like languages. Other languages do different things. In
>> the PHP manual, Hack, TypeScript, ActionScript, and most
FYI there was a very small discussion about it ~ 1 year ago
https://www.mail-archive.com/internals@lists.php.net/msg71521.html
On 11/16/2015 10:15 AM, Chris Riley wrote:
Hi,
There has been a lot of interest recently (eg psr-7) in immutable data. I'm
considering putting an RFC together to add
On 09/07/2015 08:43 AM, Sean DuBois wrote:
On Sun, Sep 06, 2015 at 06:47:56PM +0100, Andrea Faulds wrote:
Hi Sean,
Sean DuBois wrote:
I am starting this discussion to get peoples opinion on the overall feature,
and find someone
who would be interested in watching over my progress and
Hi,
today I was running into an issue with a function lookup over namespace.
https://3v4l.org/qF7cK fails
https://3v4l.org/evVic works
For me it looks like the function lookup for "is_null" in this case gets
cached on first use
and on second call no check will be done if this function exists
On 05/31/2016 09:59 PM, Nikita Popov wrote:
On Tue, May 31, 2016 at 9:54 PM, Marc Bennewitz <dev@mabe.berlin
<mailto:dev@mabe.berlin>> wrote:
Hi,
today I was running into an issue with a function lookup over
namespace.
https://3v4l.org/qF7cK fails
https://3v
1 - 100 of 150 matches
Mail list logo
