RE: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions

[Bryan C. Geraghty]

Actually, a better approach is to use /dev/urandom to seed a PRG.

See my previous email in this thread regarding the FIPS approved generators.

Bryan

-Original Message-
From: Leigh [mailto:lei...@gmail.com] 
Sent: Friday, August 30, 2013 6:27 PM
To: Marc Bennewitz
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] More powerful (and backward compatible) API of random
number generator functions

On 30 August 2013 20:58, Marc Bennewitz  wrote:

> what is the best algorithm?


Well that is platform dependant. For example on FreeBSD you'd hope
/dev/random was used (which does not block like linux, and generates a
crypto quality pseudo-random stream)

Point being, "best" is not easily defined by a constant.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions

[Bryan C. Geraghty]

First, I want to ask: Does anyone else think we should draw a distinction 
between RNGs and CSPRNGs?

I ask this because the OpenSSL option here is the only CSPRNG; The others are 
trivially breakable and should not be used for cryptographic applications. I 
could see an argument for wanting to use them in non-security contexts but I'm 
wondering if the API should make it clear when that is being done.

Secondly, a good place to look for defining a standard secure CSPRNG is FIPS 
1402 Annex C (csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf‎)

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] More powerful (and backward compatible) API of random 
number generator functions

Am 30.08.2013 04:30, schrieb Yasuo Ohgaki:
> On Thu, Aug 29, 2013 at 9:00 PM, Ángel González  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 (hopfully)
>>>
>>> const RAND_ALGO_LIBC
>>> const RAND_ALGO_MERSENNE_TWISTER
>>> const RAND_ALGO_OPENSSL
>>> const RAND_ALGO_GMP
>>>
>> (...)
>>
>>> What do you think?
>>>
>>
>> Why do you want them?
> 
> 
> This proposal is good because we need the best random function 
> available in a system with easy to use API. I would like to see the 
> best algorithm in a system as default.
> 

Defining the "best" algorithm as the standard default would be great but what 
is the best algorithm? Some are fast but less secure and other are more secure 
but slow.

Some times ago i read a feature request to implement the mersenne twister 
algorithm for rand/shuffle/array_rand but this was closed because it would be a 
bc break. (can't find it new).

Best Regards
Marc

--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Argument unpacking

[Bob Weinand]

Hi!

Am 31.8.2013 um 01:39 schrieb Lazare Inepologlou :

> 
> 
> 2013/8/31 Bob Weinand 
> Hi!
> 
> Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :
> 
> > 2013/8/30 Stas Malyshev 
> >
> >>> don't see a reason why one should explicitly disallow doing multiple
> >>> unpacks.
> >>
> >> Because it makes very hard to understand what's going on and makes no
> >> sense semantically.
> >>
> >>> As you can see, here two arguments are unpacked in one call.
> >>
> >> This is very special use case to be hidden in library functions, I don't
> >> think we need to have language syntax specially directed at that, at the
> >> cost of making it overall more complex and hard to understand. I can see
> >> what "add all those params at the end" syntax mean. However having
> >> something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea
> >> what's going on at all and what is sent where.
> >>
> >>
> > I agree with Stas here. If an argument comes after an unpacked array, its
> > position is not certain until runtime. This makes life difficult for static
> > analysis tools, which is one of the reasons for introducing the new syntax.
> 
> The alternative is for users to use what we have now: call_user_func_array
> with some array_merge, which makes it as difficult for static analysis as the
> new syntax does. This really is a non-argument.
> 
> 
> 
> Please read carefully my argument. The alternative is to actually call the 
> function normally with the arguments expanded in the code. 
> 
> In other words, the alternative to this:
> strpos( ...$array , 3 );  // which cannot be verified statically
> 
> is this:
> strpos( $array[0] , $array[1] , 3 ); // which is perfectly verifiable.
> 
> 
> The power of this proposal is found when used with optional arguments (or 
> variadic arguments) which always come last anyway.
>  
> 
> Lazare INEPOLOGLOU
> Ingénieur Logiciel

This also isn't anything it ever would write, because it just doesn't make any 
sense for two or three arguments.

In my opinion you only should unpack arrays when it's at the end … AND when you 
can verify how many parameters will be inserted. Just shorter. Because writing:

func($array[0], $array[1], $array[2], $array[3], $array[4], $array[5], 
$array[6], "value");

is just ugly to write and to read.

if (count($array) == 7)
func(...$array, "value");

is much more readable, I think.

Bob Weinand

Re: [PHP-DEV] [RFC] Argument unpacking

[Bob Weinand]

Hi!

Am 31.8.2013 um 01:39 schrieb Stas Malyshev :

> Hi!
> 
>> function short (...$args) {
>>if (count($args))
>>return long(...$args, "some value");
>> }
> 
> This is exactly the problem. Since $args has undefined number of
> arguments, there's no way to determine where "some value" ends up. Which
> means it's impossible to understand what's going on here. Now, if we had
> named arguments, like python had, then using "some value" as a named
> argument might work (and we'd need to see what to do with named
> arguments in this case), but as positional argument this just doesn't
> make much sense beyond some very esoteric things that nobody uses
> directly, without wrapping libraries (like partially applied functions)
> - at least in PHP.

That's why there is an if (count($args)) (I just forgot to add an == 7)

It should read:

function short (...$args) {
   if (count($args) == 7)
   return long(...$args, "some value");
}

And when you name the example with the "esoteric things", I'd like to have them
in the most readable format possible, which isn't achievable with 
func_get_args().

>> And I think you are really arguing about non-issues.
>> Example: Multiple uses of unpacking syntax makes sense when you call a
>> function with a variadic parameter:
>> 
>> function variadic (...$args) {
>>// do something
>> } 
>> 
>> variadic(...$array1, ...$array2);
> 
> Again, since parameters in PHP are positional, they have meaning
> depending on position. If you just wanted to pass an array, pass an
> array, you don't need to use variadic syntax for that. Variadic syntax
> makes sense only if positions there have meanings and you want to give
> specific meanings to specific arguments in specific positions. In that
> case, ...$array1, ...$array2 doesn't work since you can not have
> meaningful positions. Only case where it works if you do functional
> operations like partial application, where the meaning of the function
> is not important but only the fact that it is a function is important.
> But I don't think we need special syntax to do such things.

I mean, it looks way cleaner to use this instead of:

call_user_func_array("variadic", array_merge($array1, $array2));

And no, the order isn't always important. Example:

function variadic (...$args) {
return array_reduce($args, function ($a, $b) { return $a*$b; }, 1);
}

Yes, this is a very simple example, but just to show the idea of it.

And even when the order is important, it may be useful:

// according to implementation, arrays are expanded in insertion order here
// https://github.com/nikic/php-src/compare/variadics...splat#L11R3263
$short_default_options = [
"arg1" => 1,
"arg2" => 3,
"arg3" => 7,
];

function short (...$extra_options) {
   global $short_default_options; // in classes, this would be a 
$this->short_options
   if (count($args) <= 3)
   return long(...$short_default_options, ...$extra_options);
}

function long ($arg1, $arg2, $arg3, $arg4 = 0, $arg5 = 0, $arg6 = 0) {
// do something
}

> -- 
> 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

Re: [PHP-DEV] Re: crc32() and ip2long() return values

[Tjerk Meesters]

Hi,

On 30 Aug, 2013, at 11:29 PM, Rasmus Schultz  wrote:

> No replies probably means no one cares. oh well.
> 
> For the record, the examples I posted are wrong - the correct way to
> convert the long values consistently appears to be:
> 
> list($v) = array_values(unpack('l', pack('l', ip2long('255.255.255.0';

I recognise this from a comment on one of my SO answers here: 
http://stackoverflow.com/questions/13419921/how-should-a-crc32-be-stored-in-mysql/13420281#13420281

Instead of using list() and array_values() you can use current() on the return 
value to get the first array element from unpack()'s result. 

echo current(unpack('l', pack('l', crc32(...;
Admittedly only makes it marginally nicer to look at :)

> 
> I missed the fact that array_values() returns an array, and for some reason
> the return-value from unpack() is base-1 with apparently no way to change
> the key to a 0.
> 
> As an aside, the information I posted on the manual pages in the comments
> is wrong, and the site currently offers no way to edit or remove a
> comment... dangit...
> 
> 
> 
> On Tue, Aug 27, 2013 at 12:05 PM, Rasmus Schultz  wrote:
> 
>> Dear list,
>> 
>> I recently ran into big problems with crc32() and ip2long() both of which
>> I was using in the same codebase.
>> 
>> I know these issues have been debated at length in the past, but this
>> really needs to be fixed.
>> 
>> Anytime you persist these values (to any external medium, files or
>> databases) you're sitting on a time bomb.
>> 
>> I realize some of you have countless technical arguments why these
>> functions "work as they're supposed to", but php is a high-level language,
>> and these functions do not work consistently across platforms.
>> 
>> It can't be the developer's responsibility to write unit-tests for
>> return-values on internal functions - nor should we need to write elaborate
>> wrapper-functions for these functions to get them to work consistently.
>> 
>> There are dozens (if not nearing 100) different user-land solutions to
>> this problem, so it's not like the need isn't there - anyone who has ever
>> used these functions probably needed a work-around. The need for an
>> enormous red WARNING label, and elaborate explanation on the crc32()
>> documentation page says it all - nothing this simple, that has been
>> standardized for this long, should require an elaborate explanation,
>> complicated work-arounds or for that matter a lot of thought on the
>> developer's side.
>> 
>> Since a signed 32-bit integer value is the lowest common denominator,
>> that's what the functions ought to return, so that at least the return
>> value is consistent across platforms, and you can decide (for example)
>> whether to persist it to a signed or unsigned INT in a database, and except
>> it to work the same everywhere. (Databases at large, and at least MySQL,
>> correctly persists either signer or unsigned INT values across platforms.)
>> 
>> The simplest work-around I have been able to come up with so far, is this:
>> 
>>var_dump(unpack('l', pack('l', ip2long('255.255.255.0';
>> 
>>var_dump(unpack('l', pack('l', crc32('123456789_00_0';
>> 
>> Forcing the value into smaller (on some platforms) 32-bit integer, and
>> then unpacking it, provides a consistent value on 32-bit and 64-bit
>> systems, and on Windows.
>> 
>> Of course there is backwards compatibility to consider for this broken
>> behavior, so I propose the simplest solutions is to just add a new pair of
>> replacement functions. You don't need to deprecate the existing functions,
>> because they work as prescribed, however useless they may be for any
>> practical applications.
>> 
>> The new functions and backwards compatible implementations for older
>> versions of php might look like this:
>> 
>> /**
>> * @param string
>> * @return int a signed (32-bit) integer value
>> */
>> function ip2int($ip_string) {
>>return unpack('l', pack('l', ip2long($ip_string)));
>> }
>> 
>> /**
>> * @param int a signed integer value
>> * @return string
>> */
>> function int2ip($ip_int) {
>>return long2ip($ip_int);
>> }
>> 
>> /**
>> * @param string
>> * @return int a signed integer value
>> */
>> function crc32i($string) {
>>return unpack('l', pack('l', crc32($string)));
>> }
>> 
>> int2ip() would just be an alias for long2ip().
>> 
>> I spent almost a full day fighting with these functions and testing
>> work-arounds, and I bet every php developer who encounters a need for one
>> of these functions will some day sooner or later go through the same.
>> 
>> Userland solutions are not solutions to fundamental problems that affect
>> everyone who uses the functions.
>> 
>> Arguing that this behavior is "correct" by some technical definition, is
>> futile - the behavior is problematic for practical reasons, so technical
>> circumstances don't really matter here. Core functions need to actually
>> work consistently and predictably for as many users as possible -
>> optimizing for C devel

Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading

[Jordan DeLong]

On Fri, Aug 30, 2013 at 03:21:47PM -0700, Stas Malyshev wrote:
> Hi!
> 
> > We got a performance win from exactly this at Facebook.  We have some
> > extensions in HHVM to autoload that allowed us to remove almost all
> > our *_once calls.
> 
> But autoloading does not remove require - you still have to load the
> files. Only thing that can be removed is a non-loading require. Is it
> that frequent that it had significant performance impact (given that
> with opcode caching non-loading require is pretty much a couple of hash
> lookups)?

For us it saved unnecessary loading requires due to transitive module
dependencies, as well.  I'd suspect it is unlikely to matter in nearly
the same way on smaller codebases, though.

-Jordan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Argument unpacking

[Lazare Inepologlou]

2013/8/31 Bob Weinand 

> Hi!
>
> Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :
>
> > 2013/8/30 Stas Malyshev 
> >
> >>> don't see a reason why one should explicitly disallow doing multiple
> >>> unpacks.
> >>
> >> Because it makes very hard to understand what's going on and makes no
> >> sense semantically.
> >>
> >>> As you can see, here two arguments are unpacked in one call.
> >>
> >> This is very special use case to be hidden in library functions, I don't
> >> think we need to have language syntax specially directed at that, at the
> >> cost of making it overall more complex and hard to understand. I can see
> >> what "add all those params at the end" syntax mean. However having
> >> something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea
> >> what's going on at all and what is sent where.
> >>
> >>
> > I agree with Stas here. If an argument comes after an unpacked array, its
> > position is not certain until runtime. This makes life difficult for
> static
> > analysis tools, which is one of the reasons for introducing the new
> syntax.
>
> The alternative is for users to use what we have now: call_user_func_array
> with some array_merge, which makes it as difficult for static analysis as
> the
> new syntax does. This really is a non-argument.
>
>

Please read carefully my argument. The alternative is to actually call the
function normally with the arguments expanded in the code.

In other words, the alternative to this:
strpos( ...$array , 3 );  // which cannot be verified statically

is this:
strpos( $array[0] , $array[1] , 3 ); // which is perfectly verifiable.


The power of this proposal is found when used with optional arguments (or
variadic arguments) which always come last anyway.


Lazare INEPOLOGLOU
Ingénieur Logiciel




> And should we really restrict the user's code with some arbitrary limits?
> It just makes the user use some really ugly hacks nobody wants to see.
>
> > Even in the use case of Nikita, the two arguments to be unpacked come
> > without any standard arguments between or after them.
> >
> > I suggest that argument unpacking should be limited to the last arguments
> > only.
>
> An example where it really would make sense is:
>
> function long ($arg, $arg2, $arg3, $arg4, $arg5, $arg6, $arg7, $string) {
> // do something with your arguments
> }
>
> // just instead of copying the seven parameters; increases readability
> // and don't argue this would be badly statically analyzable - it is, but
> this isn't
> // the point. I want to show that people may find here some use case.
> function short (...$args) {
> if (count($args))
> return long(...$args, "some value");
> }
>
> > Lazare Inepologlou
> > Ingénieur Logiciel
> >
> >
> >
> > --
> >> Stanislav Malyshev, Software Architect
> >> SugarCRM: http://www.sugarcrm.com/
> >> (408)454-6900 ext. 227
>
> I finally am in favor of the proposal, because it allows removing a lot of
> ugly
> call_user_func_array calls which aren't really well readable. (and
> naturally
> because it allows passing the variadic parameters if that rfc will be
> accepted)
>
> And I think you are really arguing about non-issues.
> Example: Multiple uses of unpacking syntax makes sense when you call a
> function with a variadic parameter:
>
> function variadic (...$args) {
> // do something
> }
>
> variadic(...$array1, ...$array2);
>
>
> Bob Weinand
>
>

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Stas Malyshev]

Hi!

> As far as complicated and fragile logic, as Nikita pointed out, you
> could put all of your functions inside of a "functions,php" in a

It's the same as making it Functions.php and a class. I don't see why we
should overhaul the autoloading in the engine and add so many complexity
just to avoid writing the word "class".

> Or, alternatively, you can keep a mapping of function->filename. There's
> no need or requirement for one-class, one-function or one-constant.

One-class-per-file is a very frequent usage pattern.
One-function-per-file never happens. That's the difference.

> Furthermore, I think that's up to the community to decide how to do.
> They mostly settled on a 1-class-to-1-file rule (which was not the case
> prior to __autoload/spl_autoload). I am fully confident that they will
> find a way that makes sense, if given the ability.

This sounds like a solution in search of a problem. I don't think we
should create solutions for problems that do not exist and then tell
people "now go find some problem that may fit this neat code that I've
added to the engine". We should first identify the need and only then
mess with the engine, not the other way around.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Argument unpacking

[Stas Malyshev]

Hi!

> function short (...$args) {
> if (count($args))
> return long(...$args, "some value");
> }

This is exactly the problem. Since $args has undefined number of
arguments, there's no way to determine where "some value" ends up. Which
means it's impossible to understand what's going on here. Now, if we had
named arguments, like python had, then using "some value" as a named
argument might work (and we'd need to see what to do with named
arguments in this case), but as positional argument this just doesn't
make much sense beyond some very esoteric things that nobody uses
directly, without wrapping libraries (like partially applied functions)
- at least in PHP.

> And I think you are really arguing about non-issues.
> Example: Multiple uses of unpacking syntax makes sense when you call a
> function with a variadic parameter:
> 
> function variadic (...$args) {
> // do something
> } 
> 
> variadic(...$array1, ...$array2);

Again, since parameters in PHP are positional, they have meaning
depending on position. If you just wanted to pass an array, pass an
array, you don't need to use variadic syntax for that. Variadic syntax
makes sense only if positions there have meanings and you want to give
specific meanings to specific arguments in specific positions. In that
case, ...$array1, ...$array2 doesn't work since you can not have
meaningful positions. Only case where it works if you do functional
operations like partial application, where the meaning of the function
is not important but only the fact that it is a function is important.
But I don't think we need special syntax to do such things.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions

[Leigh]

On 30 August 2013 20:58, Marc Bennewitz  wrote:

> what is the best algorithm?


Well that is platform dependant. For example on FreeBSD you'd hope
/dev/random was used (which does not block like linux, and generates a
crypto quality pseudo-random stream)

Point being, "best" is not easily defined by a constant.

Re: [PHP-DEV] [RFC] Argument unpacking

[Bob Weinand]

Hi!

Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :

> 2013/8/30 Stas Malyshev 
> 
>>> don't see a reason why one should explicitly disallow doing multiple
>>> unpacks.
>> 
>> Because it makes very hard to understand what's going on and makes no
>> sense semantically.
>> 
>>> As you can see, here two arguments are unpacked in one call.
>> 
>> This is very special use case to be hidden in library functions, I don't
>> think we need to have language syntax specially directed at that, at the
>> cost of making it overall more complex and hard to understand. I can see
>> what "add all those params at the end" syntax mean. However having
>> something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea
>> what's going on at all and what is sent where.
>> 
>> 
> I agree with Stas here. If an argument comes after an unpacked array, its
> position is not certain until runtime. This makes life difficult for static
> analysis tools, which is one of the reasons for introducing the new syntax.

The alternative is for users to use what we have now: call_user_func_array
with some array_merge, which makes it as difficult for static analysis as the
new syntax does. This really is a non-argument.

And should we really restrict the user's code with some arbitrary limits?
It just makes the user use some really ugly hacks nobody wants to see.

> Even in the use case of Nikita, the two arguments to be unpacked come
> without any standard arguments between or after them.
> 
> I suggest that argument unpacking should be limited to the last arguments
> only.

An example where it really would make sense is:

function long ($arg, $arg2, $arg3, $arg4, $arg5, $arg6, $arg7, $string) {
// do something with your arguments
}

// just instead of copying the seven parameters; increases readability
// and don't argue this would be badly statically analyzable - it is, but this 
isn't
// the point. I want to show that people may find here some use case.
function short (...$args) {
if (count($args))
return long(...$args, "some value");
}

> Lazare Inepologlou
> Ingénieur Logiciel
> 
> 
> 
> --
>> Stanislav Malyshev, Software Architect
>> SugarCRM: http://www.sugarcrm.com/
>> (408)454-6900 ext. 227

I finally am in favor of the proposal, because it allows removing a lot of ugly
call_user_func_array calls which aren't really well readable. (and naturally
because it allows passing the variadic parameters if that rfc will be accepted)

And I think you are really arguing about non-issues.
Example: Multiple uses of unpacking syntax makes sense when you call a
function with a variadic parameter:

function variadic (...$args) {
// do something
} 

variadic(...$array1, ...$array2);


Bob Weinand


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Argument unpacking

[Stas Malyshev]

Hi!

> Not sure I get what you mean. All languages with argument unpacking
> allow this. It's not commonly needed, but there are uses for it and I

I mean this:

>>> a = [0,3]
>>> range(*a)
[0, 1, 2]

>>> a = [1]; b = [2]
>>> range(*a, *b)
  File "", line 1
range(*a, *b)
  ^
SyntaxError: invalid syntax

>>> a=[0]
>>> range(*a, 3)
  File "", line 1
SyntaxError: only named arguments may follow *expression


> don't see a reason why one should explicitly disallow doing multiple
> unpacks.

Because it makes very hard to understand what's going on and makes no
sense semantically.

> As you can see, here two arguments are unpacked in one call.

This is very special use case to be hidden in library functions, I don't
think we need to have language syntax specially directed at that, at the
cost of making it overall more complex and hard to understand. I can see
what "add all those params at the end" syntax mean. However having
something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea
what's going on at all and what is sent where.

> I tried to make sure that this does not "sneak in" but is mentioned
> prominently (it's half of the by-ref section). Anyway, as already
> mentioned in the RFC: Exceptions are how we deal with errors relating to
> Traversables in general. Yes, also in the engine. E.g. in the foreach
> implementation, if get_iterator fails an exception is thrown:
> http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_vm_def.h#4191

This is the only instance of exception in the engine, and it is very
unfortunate. However what is proposed in this RFC is using exception for
one special case of factual argument not matching function definition,
while exceptions are never used in any other case of the same problem.
This is inconsistent and wrong.

> If staying consistent with foreach is not wanted (or this is not

How calling a function can be consistent with foreach? Those are
different things. Calling a function should be consistent with all other
cases of calling a function.

> considered "consistent"), I'm also okay to turn that into a fatal error
> or into a warning where the argument will simply be passed without the
> reference-binding instead (like what we do when you pass a function call
> that returns by-value to a by-reference parameter. Though there it's
> actually just an E_STRICT.)

it should work like other instances of non-ref parameter (i.e. not a
variable and not a function returning by ref) passed to by-ref function.
Namely producing E_STRICT.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading

[Sebastian Krebs]

2013/8/31 Stas Malyshev 

> Hi!
>
> > We got a performance win from exactly this at Facebook.  We have some
> > extensions in HHVM to autoload that allowed us to remove almost all
> > our *_once calls.
>
> But autoloading does not remove require - you still have to load the
> files.


But it removes many many 'require_once's.


> Only thing that can be removed is a non-loading require. Is it
> that frequent that it had significant performance impact (given that
> with opcode caching non-loading require is pretty much a couple of hash
> lookups)?
>

Those, who doesn't wrap anything in classes, can see this very frequently.


>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
github.com/KingCrunch

Re: [PHP-DEV] [RFC] Argument unpacking

[Lazare Inepologlou]

2013/8/30 Stas Malyshev 

> > don't see a reason why one should explicitly disallow doing multiple
> > unpacks.
>
> Because it makes very hard to understand what's going on and makes no
> sense semantically.
>
> > As you can see, here two arguments are unpacked in one call.
>
> This is very special use case to be hidden in library functions, I don't
> think we need to have language syntax specially directed at that, at the
> cost of making it overall more complex and hard to understand. I can see
> what "add all those params at the end" syntax mean. However having
> something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea
> what's going on at all and what is sent where.
>
>
I agree with Stas here. If an argument comes after an unpacked array, its
position is not certain until runtime. This makes life difficult for static
analysis tools, which is one of the reasons for introducing the new syntax.

Even in the use case of Nikita, the two arguments to be unpacked come
without any standard arguments between or after them.

I suggest that argument unpacking should be limited to the last arguments
only.


Lazare Inepologlou
Ingénieur Logiciel



--
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading

[Stas Malyshev]

Hi!

> We got a performance win from exactly this at Facebook.  We have some
> extensions in HHVM to autoload that allowed us to remove almost all
> our *_once calls.

But autoloading does not remove require - you still have to load the
files. Only thing that can be removed is a non-loading require. Is it
that frequent that it had significant performance impact (given that
with opcode caching non-loading require is pretty much a couple of hash
lookups)?

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Anthony Ferrara]

Stas,

I see a number of places where hash lookup is replaced with
> zend_lookup_function, not with the macro. Moreover, zend_lookup_function
> for some reason copies and lowercases the argument, even though for hash
> lookup it should already be lowercased.


There was quite literally one place I forgot to switch to the macro
expansion (in zend_API.c, zend_is_callable_check_func). I'm sorry. That has
been rectified.

As far as it being already lowercased, based on the original implementation
before refactor, I couldn't hold that as true. So I had implemented it very
similar to lookup_class.

However, after the refactor (the current state of the patch), it is
redundant. I have pushed a commit to refactor that away.

Thanks

Anthony

Re: [PHP-DEV] [RFC] Argument unpacking

[Stas Malyshev]

Hi!

> This RFC proposes to add a syntax for argument unpacking:
> 
> https://wiki.php.net/rfc/argument_unpacking
> 
> Basically, this is the "complement" of the variadics RFC: It is not about
> declaring variadic functions, but about calling them.

This is just another way of doing call_user_func, I'm not sure we really
need it. And something like:
test(1, 2, ...[3, 4], 5, 6, ...[7, 8])

looks plain weird. What would be the use case for doing something like
that? I don't think we should add this.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Argument unpacking

[Andrey Hristov]

On 08/30/2013 05:23 PM, Nikita Popov wrote:

Hi internals!

This RFC proposes to add a syntax for argument unpacking:

 https://wiki.php.net/rfc/argument_unpacking

Basically, this is the "complement" of the variadics RFC: It is not about
declaring variadic functions, but about calling them.

The syntax it introduces looks as follows:

 $db->query($query, ...$params);

Thoughts?

Thanks,
Nikita



can't we use a new cast operator like (unpack) for this instead of the 
three dots?


$db->query($query, (unpack) $params); ?

Andrey

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions

[Marc Bennewitz]

Am 30.08.2013 04:30, schrieb Yasuo Ohgaki:
> On Thu, Aug 29, 2013 at 9:00 PM, Ángel González  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 (hopfully)
>>>
>>> const RAND_ALGO_LIBC
>>> const RAND_ALGO_MERSENNE_TWISTER
>>> const RAND_ALGO_OPENSSL
>>> const RAND_ALGO_GMP
>>>
>> (...)
>>
>>> What do you think?
>>>
>>
>> Why do you want them?
> 
> 
> This proposal is good because we need the best random function available in
> a system
> with easy to use API. I would like to see the best algorithm in a system as
> default.
> 

Defining the "best" algorithm as the standard default would be great but
what is the best algorithm? Some are fast but less secure and other are
more secure but slow.

Some times ago i read a feature request to implement the mersenne
twister algorithm for rand/shuffle/array_rand but this was closed
because it would be a bc break. (can't find it new).

Best Regards
Marc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Syntax for variadic functions

[Sebastian Krebs]

2013/8/30 jbo...@openmv.com 

> On Wed Aug 28 11:47 AM, Nikita Popov wrote:
> >
> > https://wiki.php.net/rfc/variadics
>
> Interesting idea, expanding on:
>
> function log($message, ...$options) {}
>
> It would seem convenient to allow ...$options to be passed as a key-value
> array of arguments as well:
> function logA($message, ...$options[]) {  echo count($options); }
>
> logA("foo"); // 0
> logA("foo", 1, 2); // 2
> logA("foo", array(1,2,3)); // 3
>
> The difference here is that variadic options is declared as an optional
> array, it would not support a 'typehint' forcing all arguments to be of the
> same type.
> It could be a way to support ~ named parameters
>
> // requires at least 1 argument named as 'level'
> function logB($message, ...$options['level']) {
>echo $options['level'] .' '. count($options);
> }
>
> logB("foo");// fails: 'level' argument
> missing
> logB("foo", 'notice');   //notice 1
> logB("foo", ['level' => 'notice']); // notice 1
> logB("foo", 'notice', 'extra'); // notice 2
> logB("foo", ['level' => 'notice'], 'extra'); // notice 2
>
> // requires min 2 arguments
> function logC($message, ...$options['level','priority']) {
>echo 'level:'. $options['level'];
>echo 'priority:'. $options['priority'];
> }
> logC("foo", "notice", 4);
> logC("foo", ['level' => 'notice', 'priority' => 4]);
>
> That would remove the need for a "splat" or "scatter" operator. The
> declaration "...$options[]" would mean, I accept an array of arguments
> followed by extra arguments
>

I'd recommend to use an object, or separate parameters instead. Thats not a
use-case for argument-lists.


Regards
Sebastian


>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
github.com/KingCrunch

Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions

[Marc Bennewitz]

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 RAND_ALGO_OPENSSL
>> const RAND_ALGO_GMP
> (...)
>> What do you think?
> 
> Why do you want them?

The constants exists to have a more readable (and standardizes) name of
algorithms and helps the developer which algorithms exists without
calling rand_algo_list().

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] LFS support for PHP 5.5.1

[X Ryl]

Hi,

  Please find attached a patch for adding large file size support to PHP
5.5.1.
Basically, it allows 32 bits machine to address file larger than 4GB, get
correct results when asking for their size, allows to read and write them,
etc...

It does so by, from the PHP's side, getting double instead of int for the
file size/ offset functions, when the size is larger than 2^31.

This means that files with size:
- up to 2^32 bytes works as previously (integer returned / used)
- up to 2^52 bytes can be handled correctly (double's mantissa is 52 bits,
no loss in precision here)
- from 2^52 up to 2^64 will have their size rounded, yet, reading and
writing will work as expected since it's done in the PHP's binary.

The changes are:
- Some size_t are changed to off_t wherever required.
- The code with unique mmap now loops the mmap until the complete
file/stream is done processing
- Fix for the mmap of a popen's pipe that can't work (unrelated, but easy
to fix while working on the mmap code)
- Change the return type based on the actual range of the manipulated
number (so if the value fit in a integer, a integer is used, and the code
that used to work still works, but if it does not fit, a double is used,
and the code that used to fails now works)

Please notice that I'm not a PHP developer, I don't have any time left for
maintaining this patch, but I'm sure this patch has a value. So, I deny any
right on it and put it in public domain for whoever wants to improve it,
integrate it.


Let me know your remarks.
Cyril
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] Syntax for variadic functions

[jbo...@openmv.com]

On Wed Aug 28 11:47 AM, Nikita Popov wrote:
> 
> https://wiki.php.net/rfc/variadics 

Interesting idea, expanding on:

function log($message, ...$options) {}

It would seem convenient to allow ...$options to be passed as a key-value array 
of arguments as well:
function logA($message, ...$options[]) {  echo count($options); }

logA("foo"); // 0
logA("foo", 1, 2); // 2
logA("foo", array(1,2,3)); // 3

The difference here is that variadic options is declared as an optional array, 
it would not support a 'typehint' forcing all arguments to be of the same type.
It could be a way to support ~ named parameters

// requires at least 1 argument named as 'level'
function logB($message, ...$options['level']) {
   echo $options['level'] .' '. count($options);
}

logB("foo");// fails: 'level' argument 
missing
logB("foo", 'notice');   //notice 1
logB("foo", ['level' => 'notice']); // notice 1
logB("foo", 'notice', 'extra'); // notice 2
logB("foo", ['level' => 'notice'], 'extra'); // notice 2

// requires min 2 arguments
function logC($message, ...$options['level','priority']) {
   echo 'level:'. $options['level'];
   echo 'priority:'. $options['priority'];
}
logC("foo", "notice", 4);
logC("foo", ['level' => 'notice', 'priority' => 4]);

That would remove the need for a "splat" or "scatter" operator. The declaration 
"...$options[]" would mean, I accept an array of arguments followed by extra 
arguments


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Sebastian Krebs]

2013/8/30 Stas Malyshev 

> Hi!
>
> > Well, static methods aren't the same as functions.
>
> The big difference being?
>

A function is stateless [1], a method isn't. A function operates only on
the passed parameters [1], the method operates on the parameters and the
context it inherits from the instance (non-static), or class (static and
non-static).


[1] Beside IO and "global variables"-hacks


>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>



-- 
github.com/KingCrunch

Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading

[Jordan DeLong]

On Fri, Aug 30, 2013 at 05:13:05PM +0100, Leigh wrote:
> On Aug 30, 2013 1:31 PM, "Anthony Ferrara"  wrote:
> > For constants and function calls, the benchmark shows that the difference
> > is well within the margin of error for the test (considering variances of
> > 5% to 10% were common in my running of the tests).
> >
> > So hopefully this will dispel any worry about performance regressions in
> > currently defined cases.
> >
> > The times where performance will take a hit, is with undefined functions
> > and constants. Today, an undefined function will fatal error, so this
> > performance hit would be 0, as it would enable something that's not
> > possible today.
> 
> I would assume there is actually potential for performance gain for
> functions being autoloaded in larger codebases when the *_once calls are
> removed that would normally load the common functions files.

Maybe of interest:

We got a performance win from exactly this at Facebook.  We have some
extensions in HHVM to autoload that allowed us to remove almost all
our *_once calls.

We have user code register an "autoload map" with the runtime at the
beginning of most requests (an array mapping class/function names to
which files to load), so we don't normally execute any user code to
figure out which file needs loading.  (There's various other
optimizations to avoid autoload on top of that too.)

I don't know enough about PHP internals to know if that approach would
work as well here, though.

-Jordan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: crc32() and ip2long() return values

[Rasmus Schultz]

No replies probably means no one cares. oh well.

For the record, the examples I posted are wrong - the correct way to
convert the long values consistently appears to be:

list($v) = array_values(unpack('l', pack('l', ip2long('255.255.255.0';

I missed the fact that array_values() returns an array, and for some reason
the return-value from unpack() is base-1 with apparently no way to change
the key to a 0.

As an aside, the information I posted on the manual pages in the comments
is wrong, and the site currently offers no way to edit or remove a
comment... dangit...



On Tue, Aug 27, 2013 at 12:05 PM, Rasmus Schultz  wrote:

> Dear list,
>
> I recently ran into big problems with crc32() and ip2long() both of which
> I was using in the same codebase.
>
> I know these issues have been debated at length in the past, but this
> really needs to be fixed.
>
> Anytime you persist these values (to any external medium, files or
> databases) you're sitting on a time bomb.
>
> I realize some of you have countless technical arguments why these
> functions "work as they're supposed to", but php is a high-level language,
> and these functions do not work consistently across platforms.
>
> It can't be the developer's responsibility to write unit-tests for
> return-values on internal functions - nor should we need to write elaborate
> wrapper-functions for these functions to get them to work consistently.
>
> There are dozens (if not nearing 100) different user-land solutions to
> this problem, so it's not like the need isn't there - anyone who has ever
> used these functions probably needed a work-around. The need for an
> enormous red WARNING label, and elaborate explanation on the crc32()
> documentation page says it all - nothing this simple, that has been
> standardized for this long, should require an elaborate explanation,
> complicated work-arounds or for that matter a lot of thought on the
> developer's side.
>
> Since a signed 32-bit integer value is the lowest common denominator,
> that's what the functions ought to return, so that at least the return
> value is consistent across platforms, and you can decide (for example)
> whether to persist it to a signed or unsigned INT in a database, and except
> it to work the same everywhere. (Databases at large, and at least MySQL,
> correctly persists either signer or unsigned INT values across platforms.)
>
> The simplest work-around I have been able to come up with so far, is this:
>
> var_dump(unpack('l', pack('l', ip2long('255.255.255.0';
>
> var_dump(unpack('l', pack('l', crc32('123456789_00_0';
>
> Forcing the value into smaller (on some platforms) 32-bit integer, and
> then unpacking it, provides a consistent value on 32-bit and 64-bit
> systems, and on Windows.
>
> Of course there is backwards compatibility to consider for this broken
> behavior, so I propose the simplest solutions is to just add a new pair of
> replacement functions. You don't need to deprecate the existing functions,
> because they work as prescribed, however useless they may be for any
> practical applications.
>
> The new functions and backwards compatible implementations for older
> versions of php might look like this:
>
> /**
>  * @param string
>  * @return int a signed (32-bit) integer value
>  */
> function ip2int($ip_string) {
> return unpack('l', pack('l', ip2long($ip_string)));
> }
>
> /**
>  * @param int a signed integer value
>  * @return string
>  */
> function int2ip($ip_int) {
> return long2ip($ip_int);
> }
>
> /**
>  * @param string
>  * @return int a signed integer value
>  */
> function crc32i($string) {
> return unpack('l', pack('l', crc32($string)));
> }
>
> int2ip() would just be an alias for long2ip().
>
> I spent almost a full day fighting with these functions and testing
> work-arounds, and I bet every php developer who encounters a need for one
> of these functions will some day sooner or later go through the same.
>
> Userland solutions are not solutions to fundamental problems that affect
> everyone who uses the functions.
>
> Arguing that this behavior is "correct" by some technical definition, is
> futile - the behavior is problematic for practical reasons, so technical
> circumstances don't really matter here. Core functions need to actually
> work consistently and predictably for as many users as possible -
> optimizing for C developers and people with deep technical knowledge of
> operating system and compiler specifics does not make sense for a language
> like php.
>
> Please look for reasons to agree rather than disagree out of spite.
>
> As said, I know this has been debated at length in the past, and always
> with the same outcome - but the simple fact is that these functions don't
> work for the end-users, and they do not provide proper cross-platform
> support.
>
> No one cares how integers work internally, in C, in the CPU, or in the VM,
> and it's not relevant.
>
> There is no need to put anyone through all this unnecess

Re: [PHP-DEV] [RFC] Argument unpacking

[Laruence]

On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov  wrote:
> Hi internals!
>
> This RFC proposes to add a syntax for argument unpacking:
>
> https://wiki.php.net/rfc/argument_unpacking
>
> Basically, this is the "complement" of the variadics RFC: It is not about
> declaring variadic functions, but about calling them.
>
> The syntax it introduces looks as follows:
>
> $db->query($query, ...$params);
seems so weird and ugly..

-1

thanks
>
> Thoughts?
>
> Thanks,
> Nikita



-- 
Laruence  Xinchen Hui
http://www.laruence.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Argument unpacking

[Nikita Popov]

On Fri, Aug 30, 2013 at 7:45 PM, Stas Malyshev wrote:

> Hi!
>
> > Assuming you mean call_user_func_array, yes. This is just syntax sugar
> > for call_user_func_array. Advantages of this syntax over cufa are
> > outlined here:
> >
> https://wiki.php.net/rfc/argument_unpacking#advantages_over_call_user_func_array
>
> The only case that I see that could make sense is $db->query($query,
> ...$params).
>

> Multiple unpackings make no sense to me, as it is impossible to know
> which argument ends up where and no corresponding syntax exists on
> function side. Also, no other language as far as I can see allows it.
>

Not sure I get what you mean. All languages with argument unpacking allow
this. It's not commonly needed, but there are uses for it and I don't see a
reason why one should explicitly disallow doing multiple unpacks.

If you want a practical example for this, consider partial application,
where you bind a number of arguments to a function.

An "old-style" definition for this (no variadics syntax, no argument
unpack) would look like this:

function bind(callable $function) {
$boundArgs = array_slice(func_get_args(), 1);
return function() use ($function, $boundArgs) {
return call_user_func_array(
$function, array_merge($boundArgs, func_get_args()
);
}
}

The equivalent new-style definition with variadics syntax and argument
unpacking:

function bind(callable $function, ...$boundArgs) {
return function(...$args) use($function, $boundArgs) {
return $function(...$boundArgs, ...$args);
}
}

As you can see, here two arguments are unpacked in one call.


> Also, I just noticed the RFC  tries to sneak in the exception throwing
> in the syntax construct, which we agreed not to do a long time ago and
> which was never done in the engine. We shouldn't do this - if you want
> to change PHP error handling, it should be in separate RFC for this
> purpose.
>

I tried to make sure that this does not "sneak in" but is mentioned
prominently (it's half of the by-ref section). Anyway, as already mentioned
in the RFC: Exceptions are how we deal with errors relating to Traversables
in general. Yes, also in the engine. E.g. in the foreach implementation, if
get_iterator fails an exception is thrown:
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_vm_def.h#4191

If staying consistent with foreach is not wanted (or this is not considered
"consistent"), I'm also okay to turn that into a fatal error or into a
warning where the argument will simply be passed without the
reference-binding instead (like what we do when you pass a function call
that returns by-value to a by-reference parameter. Though there it's
actually just an E_STRICT.)

Nikita

Re: [PHP-DEV] [RFC] Argument unpacking

[Lazare Inepologlou]

2013/8/30 Stas Malyshev 

> Hi!
>
> > This RFC proposes to add a syntax for argument unpacking:
> >
> > https://wiki.php.net/rfc/argument_unpacking
> >
> > Basically, this is the "complement" of the variadics RFC: It is not about
> > declaring variadic functions, but about calling them.
>
> This is just another way of doing call_user_func, I'm not sure we really
> need it. And something like:
> test(1, 2, ...[3, 4], 5, 6, ...[7, 8])
>
> looks plain weird. What would be the use case for doing something like
> that? I don't think we should add this.
>
>
Yes, this example is weird, because every argument is hardcoded anyway. I
guess it has been added just for completeness.

A good example would be function forwarding for variadic functions, without
resorting to call_user_func_array.

An even better example is that there would be no need to have both
call_user_func and call_user_func_array in the first place: The former
would be enough. The same applies to userland functions, and I have been
many times in a situation where I had to define two different functions to
cover both cases.



Lazare INEPOLOGLOU
Ingénieur Logiciel



> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [PATCH] LFS support for PHP 5.5.1

[X Ryl]

On Fri, Aug 30, 2013 at 4:52 PM, Johannes Schlüter
 wrote:
>
> On Fri, 2013-08-30 at 16:43 +0200, X Ryl wrote:
> > Hi,
> >
> >
> >   Please find attached a patch for adding large file size support to
> > PHP 5.5.1.
>
> The patch didn't make it. Please send as text/plain (i.e. using .txt
> extension)


Done.

>
>
> > It does so by, from the PHP's side, getting double instead of int for
> > the file size/ offset functions, when the size is larger than 2^31.
>
> This has some problems - for further handling onemight need the exact
> file size (i.e. content length headers, checking structures, reading
> specific positions)
>
> > This means that files with size:
> > - up to 2^32 bytes works as previously (integer returned / used)
> > - up to 2^52 bytes can be handled correctly (double's mantissa is 52
> > bits, no loss in precision here)
>
> This might work for the initial operation, but as soon as the user does
> a calculation ("give me the last ten bytes") this will cause issues.

No it won't. double mantissa are integers, works like integer.
So you have the complete 52 bits of precision here, not a single
rounding error can occur.
The exponent in that case will be 0, so "2^0 * integer_with_52_bits"
is still an integer with 52 bits of precision.

So the "filesize - 10" is still exact as long as the filesize is less
than 2^52 (see below when it's larger)



>
> > - from 2^52 up to 2^64 will have their size rounded, yet, reading and
> > writing will work as expected since it's done in the PHP's binary.

I'll try to improve this, since it's causing misunderstanding.
Typically, when you start storing a value that does not fit in 52
bits, it's shifted (understand: round to the closed multiple of two)
until it fits the range.
So for example, a file size that's "2^53 + 203" will be stored as
9007199254741196 instead of 9007199254741195 (the error is 1 here)

Yet, the reported value will be wrong, but if you seek close to the
end position and read it you'll still be able to read it completely
(since the  double value will be converted back to 
64-bit integer in the C code). As long as you're dealing with
positions/seek in a multiple of 2^52, you'll be fine.
So if you need 100% correct value for such a large file, you can still
do it by looping, AT WORST, 4096 times ( = 2^64 / 2^52) a seek with
SEEK_CUR.
Not a real showstopper when the current version does not even allow
you to know the actual size of the file, not even speaking of reading
it!)

If you either have to handle such large file NOW, then chance are high
you're already using a 64 bits system.
This patch if for us, poor souls, struck with 32 bits system, yet
wanting to report correct size for our movies in our web-based file
manager, wanting to stream correctly such files and so on.

> >
> >
> > The changes are:
> > - Some size_t are changed to off_t wherever required.
>
> This disqualifies from 5.5 and allows use in 5.6 only.

Ok
Cyril
diff -ur php-5.5.1/ext/phar/phar_internal.h 
php-5.5.1.new/ext/phar/phar_internal.h
--- php-5.5.1/ext/phar/phar_internal.h  2013-07-18 16:37:33.0 +0200
+++ php-5.5.1.new/ext/phar/phar_internal.h  2013-08-15 10:42:39.332887601 
+0200
@@ -534,8 +534,15 @@
return FAILURE;
 }
 #else
-# define phar_stream_copy_to_stream(src, dest, maxlen, len)
_php_stream_copy_to_stream_ex((src), (dest), (maxlen), (len) STREAMS_CC 
TSRMLS_CC)
-
+static inline size_t phar_stream_copy_to_stream(php_stream *src, php_stream 
*dest, size_t maxlen, size_t *len)
+{
+   off_t _maxlen = maxlen == (size_t)PHP_STREAM_COPY_ALL ? 
PHP_STREAM_COPY_ALL : maxlen, _len = 0;
+   size_t ret = php_stream_copy_to_stream_ex(src, dest, _maxlen, &_len);
+   if (ret == SUCCESS) {
+   if (len) *len = (size_t)_len;
+   } else if (len) *len = 0;
+   return ret;
+}
 #endif
 
 #if PHP_VERSION_ID >= 6
diff -ur php-5.5.1/ext/standard/file.c php-5.5.1.new/ext/standard/file.c
--- php-5.5.1/ext/standard/file.c   2013-07-18 16:37:33.0 +0200
+++ php-5.5.1.new/ext/standard/file.c   2013-08-15 10:42:39.432888125 +0200
@@ -570,7 +570,7 @@
char *filename;
int filename_len;
zval *data;
-   int numbytes = 0;
+   off_t numbytes = 0;
long flags = 0;
zval *zcontext = NULL;
php_stream_context *context = NULL;
@@ -618,7 +618,7 @@
 
switch (Z_TYPE_P(data)) {
case IS_RESOURCE: {
-   size_t len;
+   off_t len;
if (php_stream_copy_to_stream_ex(srcstream, stream, 
PHP_STREAM_COPY_ALL, &len) != SUCCESS) {
numbytes = -1;
} else {
@@ -635,9 +635,9 @@
 
case IS_STRING:
if (Z_STRLEN_P(data)) {
-   numbytes = php_stream_write(stream, 
Z_STRVAL_P(data), Z_STRLEN_P(data));
-   if (numbytes != Z_STRLEN_P(data)) {
- 

Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]

[Levi Morrison]

I definitely do not want a NON_STRICT mode for interpreting JSON. A
NON_STRICT mode is a very bad idea, no matter how well intentioned.

Re: [PHP-DEV] Re: crc32() and ip2long() return values

[Matthew Leverton]

On Fri, Aug 30, 2013 at 11:48 AM, Rasmus Schultz  wrote:
> array(2) {
>   [2130706433]=>
>   string(3) "foo"
>   ["4294967040"]=>
>   string(3) "bar"
> }
>
> The keys are now two different types (string vs int) on 32-bit platforms,
> which leads to problems with strict comparison.
>
Prefix your keys with any alpha char to enforce a consistent string type.

> Another issue is persistence - if you save these to unsigned integer columns
> in database, and your data access layer converts them back to integers on
> load, the values are going to change again depending on what platform you're
> on.
>
I've never had that issue with any database layer I've ever worked
with. Not saying that no such db layer exists, but if you use PHP with
big integers, then you should treat them as strings in and out. If you
want to do math on them, then you have to use one of the bigint
libraries. If you want them for display purposes, keep them as
strings.

> To quote the specific case where I encountered this, I have an audit trail
> system that logs a lot of user activity - as an optimization, I hash and
> store certain keys using crc32() numeric values, since storing a 32-bit
> number is much cheaper (in terms of storage) than storing strings, as well
> as giving much faster queries.
>
Again, you should be able to store them from a string int to database
int without any issues. If so, I'd suggest fixing this at the database
access layer.

> Why would you consider a consistent function "crippled"?
>
It's crippled in the sense that it punishes people who are using
modern hardware from intelligently processing the return value. I have
a 64-bit system, and it returns a negative number for a 32-bit CRC?

> Look at the sheer number of comments on the crc32 manual page and tell me if
> you still think this works well for anybody... many of the comments
> (including mine!) aren't even correct and don't lead to predictable
> results...
>
A lot of PHP functions have tons of user error from people who haven't
bothered to read the existing manual entry or other comments.

> This should be easy but it is extremely hard.
>
There should never be the expectation that things "just work" without
having to understand the core features and limitations of the
language. To me, the examples you are giving are just two cases of the
larger problem of 32 vs 64 bit. There really is no getting around the
fact that scripts with integers behave differently depending on the
system.

So while I don't mean to sound dismissive of your complaints (because
they are valid), I just don't see how two bandaids over specific
instances of a larger problem do much good. Although, to be pragmatic,
I offered what I feel is a better solution than your extra functions.

--
Matthew Leverton

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Argument unpacking

[Nikita Popov]

Hi internals!

This RFC proposes to add a syntax for argument unpacking:

https://wiki.php.net/rfc/argument_unpacking

Basically, this is the "complement" of the variadics RFC: It is not about
declaring variadic functions, but about calling them.

The syntax it introduces looks as follows:

$db->query($query, ...$params);

Thoughts?

Thanks,
Nikita

Re: [PHP-DEV] [RFC] Argument unpacking

[Lazare Inepologlou]

2013/8/30 Stas Malyshev 

> Hi!
>
> > A good example would be function forwarding for variadic functions,
> > without resorting to call_user_func_array.
>
> What's wrong with "resorting to" call_user_func_array?
> call_user_func_array is a PHP function and not some dark magic that one
> should avoid using unless it is absolutely must.
>
>
The disadvantages of call_user_func_array are very well described in the
RFC.

Lazare INEPOLOGLOU
Ingénieur Logiciel


> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

Re: [PHP-DEV] [RFC] Argument unpacking

[Stas Malyshev]

Hi!

> A good example would be function forwarding for variadic functions,
> without resorting to call_user_func_array.

What's wrong with "resorting to" call_user_func_array?
call_user_func_array is a PHP function and not some dark magic that one
should avoid using unless it is absolutely must.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Stas Malyshev]

Hi!

> This seems to be the core of your argumentation in this thread: "Why
> don't you just use Foo::bar() instead of foo\bar()?"
> 
> In which case, I wonder why we have functions at all. We could just use
> static methods instead after all. Maybe we should deprecate function
> support?

Maybe we should stop strawman arguments? I never claimed functions
should be replaced with static methods or that we should deprecate
anything, please don't put words in my mouth.
What I claimed is that if you write code in a *specific pattern*, that
is the only pattern that makes this proposal useful and that is, as far
as I can see, in no way common among people that use functions, then *in
this specific case* you could as well use slightly different pattern
which would allow you to use existing facilities, and the only
difference between the two is the word "class" and using :: instead of \.

> On a more serious note: If you want an actual example of how functions
> can be easier to use than static methods, consider the "use function"
> RFC. Now that it's in, it is possible to directly import a function
> foo\bar() and use it with just bar(). Static methods allow no such
> thing. You always need to write the class name.

Which is a good thing. Making different thing mean the same is not a
good idea, it reduces readability. And typing 2 characters less was
never a priority.

> The reason why people currently resort to using static methods instead
> of functions is the fact that there is no autoloading for functions.
> With autoloading, functions become a lot easier to use.

I don't accept this "resort to" - static functions is not something that
one should "resort to", it is a completely valid syntactic construct.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Argument unpacking

[Stas Malyshev]

Hi!

> Assuming you mean call_user_func_array, yes. This is just syntax sugar
> for call_user_func_array. Advantages of this syntax over cufa are
> outlined here:
> https://wiki.php.net/rfc/argument_unpacking#advantages_over_call_user_func_array

The only case that I see that could make sense is $db->query($query,
...$params).

Multiple unpackings make no sense to me, as it is impossible to know
which argument ends up where and no corresponding syntax exists on
function side. Also, no other language as far as I can see allows it.

Also, I just noticed the RFC  tries to sneak in the exception throwing
in the syntax construct, which we agreed not to do a long time ago and
which was never done in the engine. We shouldn't do this - if you want
to change PHP error handling, it should be in separate RFC for this
purpose.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: crc32() and ip2long() return values

[Rasmus Schultz]

Perhaps this illustrates the problem better:

$value = sprintf('%u', ip2long('255.255.255.0'));
var_dump($value, (int) $value);

$a = array();
$a[$value] = 'foo';
var_dump($a);

Output on 64-bit:

string(10) "4294967040"
int(4294967040)
array(1) {
  [4294967040]=>
  string(3) "foo"
}

No problem.

But - output on 32-bit:

string(10) "4294967040"
int(2147483647)
array(1) {
  ["4294967040"]=>
  string(3) "foo"
}

In this example, $value and (int) $value lead to incompatible results -
that's if your database access layer will let you store a string in an
integer column in the first place. Which, even if it will, when you get the
integer value back from the database and cast it to an integer, you have
the same problem again. If you query against the database using integer
values you computed, you have problems. And so on...



On Fri, Aug 30, 2013 at 12:27 PM, Matthew Leverton wrote:

> On Fri, Aug 30, 2013 at 10:29 AM, Rasmus Schultz 
> wrote:
> > No replies probably means no one cares. oh well.
> >
> > For the record, the examples I posted are wrong - the correct way to
> > convert the long values consistently appears to be:
> >
> > list($v) = array_values(unpack('l', pack('l',
> ip2long('255.255.255.0';
> >
> I had spotted the error, but didn't want to reply because I don't
> really understand what you are getting at.
>
> The core issue is that PHP doesn't provide a 32-bit unsigned integer
> on a 32-bit platform ... and/or that the size of integer changes
> depending on the platform. But I doubt that is going to change any
> time soon. Crippling 64-bit systems due to old, legacy 32-bit
> platforms is shortsighted.
>
> What's wrong with the manual's approach?
>
> $checksum = sprintf("%u", crc32("The quick brown fox jumped over the
> lazy dog."));
>
> Are you going to do further mathematical operations on it? You can
> take that string and stuff it into an uint32 field into a db without
> an issue.
>
> At the end of the day, there's no getting around that PHP programmers
> need to be aware of the difference between 32-bit and 64-bit systems
> ... it affects far more than these two particular functions.
>
> But if these two functions are particularly bothersome, a better "fix"
> IMO is just:
>
> $crc = crc32("12341234", CRC32_UINT32_STRING);
>
> Where the second parameter is CRC32_INT (default & current behavior),
> CRC32_INT32 (always negative if high bit is set), CRC32_UINT32_STRING,
> CRC32_HEX_STRING
>
> Forgive the poor names.
>
> --
> Matthew Leverton
>

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Nikita Popov]

On Fri, Aug 30, 2013 at 7:10 PM, Stas Malyshev wrote:

> Hi!
>
> > Well, static methods aren't the same as functions.
>
> The big difference being?
>

This seems to be the core of your argumentation in this thread: "Why don't
you just use Foo::bar() instead of foo\bar()?"

In which case, I wonder why we have functions at all. We could just use
static methods instead after all. Maybe we should deprecate function
support?

On a more serious note: If you want an actual example of how functions can
be easier to use than static methods, consider the "use function" RFC. Now
that it's in, it is possible to directly import a function foo\bar() and
use it with just bar(). Static methods allow no such thing. You always need
to write the class name.

The reason why people currently resort to using static methods instead of
functions is the fact that there is no autoloading for functions. With
autoloading, functions become a lot easier to use.

Nikita

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Tyler Sommer]

On Aug 30, 2013, at 10:25 AM, Stas Malyshev  wrote:

> 
>> Furthermore, I think that's up to the community to decide how to do.
>> They mostly settled on a 1-class-to-1-file rule (which was not the case
>> prior to __autoload/spl_autoload). I am fully confident that they will
>> find a way that makes sense, if given the ability.
> 
> This sounds like a solution in search of a problem. I don't think we
> should create solutions for problems that do not exist and then tell
> people "now go find some problem that may fit this neat code that I've
> added to the engine". We should first identify the need and only then
> mess with the engine, not the other way around.
> 

The problem exists: us users need a way to better organize our procedural 
codebases than manually managing a million require statements. You guys have 
now given us importing of functions, which is a great step forward. But we 
still need a way to intelligently load them.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Re: crc32() and ip2long() return values

[Rasmus Schultz]

Matthew,

To give another example:

var_dump(array(sprintf('%u', ip2long('127.0.0.1')) => 'foo', sprintf('%u',
ip2long('255.255.255.0')) => 'bar'));

array(2) {
  [2130706433]=>
  string(3) "foo"
  ["4294967040"]=>
  string(3) "bar"
}

The keys are now two different types (string vs int) on 32-bit platforms,
which leads to problems with strict comparison.

Another issue is persistence - if you save these to unsigned integer
columns in database, and your data access layer converts them back to
integers on load, the values are going to change again depending on what
platform you're on.

To quote the specific case where I encountered this, I have an audit trail
system that logs a lot of user activity - as an optimization, I hash and
store certain keys using crc32() numeric values, since storing a 32-bit
number is much cheaper (in terms of storage) than storing strings, as well
as giving much faster queries.

I encountered all of the problems mentioned while debugging an error in
this system, and it seems completely bonkers to have to spend this much
time on something that ought to be totally trivial, and would have been, if
these functions returned consistent results on all platforms.

Why would you consider a consistent function "crippled"?

Look at the sheer number of comments on the crc32 manual page and tell me
if you still think this works well for anybody... many of the comments
(including mine!) aren't even correct and don't lead to predictable
results...

This should be easy but it is extremely hard.

In my opinion, the function is "crippled" as it is...



On Fri, Aug 30, 2013 at 12:27 PM, Matthew Leverton wrote:

> On Fri, Aug 30, 2013 at 10:29 AM, Rasmus Schultz 
> wrote:
> > No replies probably means no one cares. oh well.
> >
> > For the record, the examples I posted are wrong - the correct way to
> > convert the long values consistently appears to be:
> >
> > list($v) = array_values(unpack('l', pack('l',
> ip2long('255.255.255.0';
> >
> I had spotted the error, but didn't want to reply because I don't
> really understand what you are getting at.
>
> The core issue is that PHP doesn't provide a 32-bit unsigned integer
> on a 32-bit platform ... and/or that the size of integer changes
> depending on the platform. But I doubt that is going to change any
> time soon. Crippling 64-bit systems due to old, legacy 32-bit
> platforms is shortsighted.
>
> What's wrong with the manual's approach?
>
> $checksum = sprintf("%u", crc32("The quick brown fox jumped over the
> lazy dog."));
>
> Are you going to do further mathematical operations on it? You can
> take that string and stuff it into an uint32 field into a db without
> an issue.
>
> At the end of the day, there's no getting around that PHP programmers
> need to be aware of the difference between 32-bit and 64-bit systems
> ... it affects far more than these two particular functions.
>
> But if these two functions are particularly bothersome, a better "fix"
> IMO is just:
>
> $crc = crc32("12341234", CRC32_UINT32_STRING);
>
> Where the second parameter is CRC32_INT (default & current behavior),
> CRC32_INT32 (always negative if high bit is set), CRC32_UINT32_STRING,
> CRC32_HEX_STRING
>
> Forgive the poor names.
>
> --
> Matthew Leverton
>

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Stas Malyshev]

Hi!

> A function is stateless [1], a method isn't. A function operates only on
> the passed parameters [1], the method operates on the parameters and the
> context it inherits from the instance (non-static), or class (static and
> non-static).

Static method is stateless in the same meaning as unattached function
is. Both can keep state in static variables if you wish. So no
difference at all, public static method is just a namespaced function.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Argument unpacking

[Nikita Popov]

On Fri, Aug 30, 2013 at 6:57 PM, Stas Malyshev wrote:

> And something like:
> test(1, 2, ...[3, 4], 5, 6, ...[7, 8])
>
> looks plain weird. What would be the use case for doing something like
> that?


No use case at all. This is a technical specification, so I write down what
is possible, not necessarily what you'd write in your code. Of course it
makes no sense to write something like ...[1, 2, 3], because you could just
as well write 1, 2, 3 directly. The point of that example is that it's
possible to mix it with normal arguments. The "practical" example for that
is the example in the introduction: $db->query($query, ...$params). Here a
"normal" argument is followed by an unpacked argument.

> This is just another way of doing call_user_func, I'm not sure we really
need it.

Assuming you mean call_user_func_array, yes. This is just syntax sugar for
call_user_func_array. Advantages of this syntax over cufa are outlined
here:
https://wiki.php.net/rfc/argument_unpacking#advantages_over_call_user_func_array

Thanks,
Nikita

Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading

[Leigh]

On Aug 30, 2013 1:31 PM, "Anthony Ferrara"  wrote:
> For constants and function calls, the benchmark shows that the difference
> is well within the margin of error for the test (considering variances of
> 5% to 10% were common in my running of the tests).
>
> So hopefully this will dispel any worry about performance regressions in
> currently defined cases.
>
> The times where performance will take a hit, is with undefined functions
> and constants. Today, an undefined function will fatal error, so this
> performance hit would be 0, as it would enable something that's not
> possible today.

I would assume there is actually potential for performance gain for
functions being autoloaded in larger codebases when the *_once calls are
removed that would normally load the common functions files.

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Stas Malyshev]

Hi!

> So nothing changes from present (at all) unless a function is not
> defined. Today, that's an error case. So the only performance change
> occurs if zend_hash_find (which is already there) returns FAILURE. THEN
> the logic which includes autoloading would run.

I see a number of places where hash lookup is replaced with
zend_lookup_function, not with the macro. Moreover, zend_lookup_function
for some reason copies and lowercases the argument, even though for hash
lookup it should already be lowercased.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Stas Malyshev]

Hi!

> Just to say : one benefit of this work would be to finally have autoload
> functionnality (which is a Core feature IMO) included in Zend/ and no more
> in an extension.

PHP core already has autoload functionality. And I don't see how with
function autoloading (which has no natural mapping at all) it is even
possible to have any mapping worth including into core as a standard.
Most functional code I've seen isn't even namespaced, and if you already
convert old code to namespaces and need autoloading, you could as well
wrap it in a class - I don't see why it's not possible.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Stas Malyshev]

Hi!

> Well, static methods aren't the same as functions.

The big difference being?

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: crc32() and ip2long() return values

[Matthew Leverton]

On Fri, Aug 30, 2013 at 10:29 AM, Rasmus Schultz  wrote:
> No replies probably means no one cares. oh well.
>
> For the record, the examples I posted are wrong - the correct way to
> convert the long values consistently appears to be:
>
> list($v) = array_values(unpack('l', pack('l', ip2long('255.255.255.0';
>
I had spotted the error, but didn't want to reply because I don't
really understand what you are getting at.

The core issue is that PHP doesn't provide a 32-bit unsigned integer
on a 32-bit platform ... and/or that the size of integer changes
depending on the platform. But I doubt that is going to change any
time soon. Crippling 64-bit systems due to old, legacy 32-bit
platforms is shortsighted.

What's wrong with the manual's approach?

$checksum = sprintf("%u", crc32("The quick brown fox jumped over the
lazy dog."));

Are you going to do further mathematical operations on it? You can
take that string and stuff it into an uint32 field into a db without
an issue.

At the end of the day, there's no getting around that PHP programmers
need to be aware of the difference between 32-bit and 64-bit systems
... it affects far more than these two particular functions.

But if these two functions are particularly bothersome, a better "fix"
IMO is just:

$crc = crc32("12341234", CRC32_UINT32_STRING);

Where the second parameter is CRC32_INT (default & current behavior),
CRC32_INT32 (always negative if high bit is set), CRC32_UINT32_STRING,
CRC32_HEX_STRING

Forgive the poor names.

--
Matthew Leverton

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading

[Laruence]

On Sat, Aug 31, 2013 at 12:13 AM, Leigh  wrote:
> On Aug 30, 2013 1:31 PM, "Anthony Ferrara"  wrote:
>> For constants and function calls, the benchmark shows that the difference
>> is well within the margin of error for the test (considering variances of
>> 5% to 10% were common in my running of the tests).
>>
>> So hopefully this will dispel any worry about performance regressions in
>> currently defined cases.
>>
>> The times where performance will take a hit, is with undefined functions
>> and constants. Today, an undefined function will fatal error, so this
>> performance hit would be 0, as it would enable something that's not
>> possible today.
>
> I would assume there is actually potential for performance gain for
> functions being autoloaded in larger codebases when the *_once calls are
> removed that would normally load the common functions files.

I just reply to this point:

No. thinking we already have opcache there. so, *compiling* Functions is cheap.

but if with function autoloading, *function autoloading* will execute every run.

thanks

-- 
Laruence  Xinchen Hui
http://www.laruence.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Stas Malyshev]

Hi!

> And to continue the discussion, I recall that we, as PHP contributors,
> disagreed to include a PSR-0 compatible autoloader into Core.

This has nothing to do with PSR-0 in core. This has everything to do
with the fact that class-per-file is an accepted pattern in PHP and many
other languages, and considered by many to be the best practice.
However, nobody uses function-per-file.

> Perhaps is it also time to talk about this subject back and finally all
> agree on a default recommanded implentation of autoloading in PHP
> (internally supported) ?

Again, it does not matter *how* classes are matched to files and where
the slashes are put in. What matters is that classes and files are
roughly in one-to-one correspondence (there are exceptions, but there
are just that - exceptions - and usually for classes that aren't part of
public API). So I'd like not to sidetrack the discussion into discussing
which way of putting slashes in is the best and whether PHP core should
have backslash-to-forward-slash function. It is not what it is about.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Argument unpacking

[Levi Morrison]

On Fri, Aug 30, 2013 at 10:33 AM, Laruence  wrote:

> On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov 
> wrote:
> > Hi internals!
> >
> > This RFC proposes to add a syntax for argument unpacking:
> >
> > https://wiki.php.net/rfc/argument_unpacking
> >
> > Basically, this is the "complement" of the variadics RFC: It is not about
> > declaring variadic functions, but about calling them.
> >
> > The syntax it introduces looks as follows:
> >
> > $db->query($query, ...$params);
> seems so weird and ugly..
>
> -1
>
> thanks


Compared to the current alternatives it's definitely less ugly. I'm all for
this syntax addition.

Re: [PHP-DEV] [PATCH] LFS support for PHP 5.5.1

[Johannes Schlüter]

On Fri, 2013-08-30 at 16:43 +0200, X Ryl wrote:
> Hi,
> 
> 
>   Please find attached a patch for adding large file size support to
> PHP 5.5.1.

The patch didn't make it. Please send as text/plain (i.e. using .txt
extension)

> It does so by, from the PHP's side, getting double instead of int for
> the file size/ offset functions, when the size is larger than 2^31.

This has some problems - for further handling onemight need the exact
file size (i.e. content length headers, checking structures, reading
specific positions)

> This means that files with size:
> - up to 2^32 bytes works as previously (integer returned / used)
> - up to 2^52 bytes can be handled correctly (double's mantissa is 52
> bits, no loss in precision here)

This might work for the initial operation, but as soon as the user does
a calculation ("give me the last ten bytes") this will cause issues.

> - from 2^52 up to 2^64 will have their size rounded, yet, reading and
> writing will work as expected since it's done in the PHP's binary.
> 
> 
> The changes are: 
> - Some size_t are changed to off_t wherever required.

This disqualifies from 5.5 and allows use in 5.6 only.

johannes




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Bryan C. Geraghty]

Having said that, I think the overall concept of function autoloading is a
useful feature and haven't seen a good argument for why it shouldn't be
supported.

Bryan

-Original Message-
From: Bryan C. Geraghty [mailto:br...@ravensight.org] 
Sent: Friday, August 30, 2013 8:13 AM
To: 'Julien Pauli'
Cc: 'internals@lists.php.net'
Subject: RE: [PHP-DEV] [DRAFT] [RFC] Function autoloading

The problem I see with implementing this kind of functionality in Core is
that it relies heavily on convention; PSR-0 is specifically a configuration
of the core autoloader which allows any configuration, as it should. And
while most of the community has adopted PSR-0 (as have I), I do not think
Core is the place for it.

Bryan

-Original Message-
From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of
Julien Pauli
Sent: Friday, August 30, 2013 3:50 AM
To: Anthony Ferrara
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading


Just to say : one benefit of this work would be to finally have autoload
functionnality (which is a Core feature IMO) included in Zend/ and no more
in an extension.

Julien.Pauli


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Bryan C. Geraghty]

The problem I see with implementing this kind of functionality in Core is
that it relies heavily on convention; PSR-0 is specifically a configuration
of the core autoloader which allows any configuration, as it should. And
while most of the community has adopted PSR-0 (as have I), I do not think
Core is the place for it.

Bryan

-Original Message-
From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of
Julien Pauli
Sent: Friday, August 30, 2013 3:50 AM
To: Anthony Ferrara
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading


Just to say : one benefit of this work would be to finally have autoload
functionnality (which is a Core feature IMO) included in Zend/ and no more
in an extension.

Julien.Pauli


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading

[Nicolas Grekas]

Hi

The only regression can be where autoloaders are defined, and people are
> relying on the legacy undefined constant behavior (which triggers an
> E_NOTICE).
>


that makes me think about this code :



What autoload should be triggered?
"foo\bar" or "bar"?

Both are valid isn't it?

Should autoloading functions and constants be restricted to namespaced ones
only?
Then the BC issue you spot would disappear.

[PHP-DEV] Re: [DRAFT] [RFC] Function autoloading

[Anthony Ferrara]

All,

I have updated the RFC to include 2 new benchmarks.

For normal class loading, this proposal shows at worst no change to loading
time. At best, it may actually improve it because at least one
zend_function_call is avoided (to spl_autoload_call).

For constants and function calls, the benchmark shows that the difference
is well within the margin of error for the test (considering variances of
5% to 10% were common in my running of the tests).

So hopefully this will dispel any worry about performance regressions in
currently defined cases.

The times where performance will take a hit, is with undefined functions
and constants. Today, an undefined function will fatal error, so this
performance hit would be 0, as it would enable something that's not
possible today.

The only regression can be where autoloaders are defined, and people are
relying on the legacy undefined constant behavior (which triggers an
E_NOTICE).

Anthony


On Thu, Aug 29, 2013 at 9:23 PM, Anthony Ferrara wrote:

> All,
>
> I have created a new draft RFC implementing function and constant
> autoloading in master:
>
> https://wiki.php.net/rfc/function_autoloading
>
> All feedback is welcome.
>
> Thanks
>
> Anthony
>

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Anthony Ferrara]

Stas,


On Fri, Aug 30, 2013 at 12:57 AM, Stas Malyshev wrote:

> Hi!
>
> > I have created a new draft RFC implementing function and constant
> > autoloading in master:
> >
> > https://wiki.php.net/rfc/function_autoloading
> >
> > All feedback is welcome.
>
> I think it is an unnecessary complication. Classes fit autoloader
> paradigm nicely, since the usual pattern is one class per one file
> (actually recommended in PSR), so it is easy to establish one-to-one
> automatic mapping between classes and files (also recommended in the
> PSR). But for functions nobody does this. This means that to implement
> function autoloader one will need to have a complicated and fragile
> logic (since there's no way to ensure this logic would be in sync with
> actual content of files containing multiple functions).


I don't think that's a fair argument. It's a bit "We don't support function
autoloading, so function autoloading doesn't make sense".

As far as complicated and fragile logic, as Nikita pointed out, you could
put all of your functions inside of a "functions,php" in a particular
namespace. Then, with use function, you can capture the missing function
call, and cut off the function name, require_once
/path/to/namespace/functions.php, and be good.

Or, alternatively, you can keep a mapping of function->filename. There's no
need or requirement for one-class, one-function or one-constant.

Furthermore, I think that's up to the community to decide how to do. They
mostly settled on a 1-class-to-1-file rule (which was not the case prior to
__autoload/spl_autoload). I am fully confident that they will find a way
that makes sense, if given the ability.


> Putting autoloading of different entities into one function makes very
> little sense to me - why would the same code load both classes and
> functions? How would it do that besides ugly switch that just stuffs two
> completely different logic pieces into one function for no reason? The
> example given in the RFC is certainly not what anybody would actually
> want their autoloaders to do, so I fail to see any case for doing it and
> for putting loading more than one entity into one function (that given
> that autoloading function would be desirable at all, which it still
> doesn't seem so for me).
>

That's why this is a RFC which is up for discussion. That's why this is a
draft instead of a proposal. Would you rather see:

bool php\autoload_class_register($callback, $prepend))
bool php\autoload_function_register($callback, $prepend)
bool php\autoload_constant_register($callback, $prepend)

Would you rather having the single autoload regstier, but enforcing that
type must be a single type?

Would you rather see interfaces?

interface php\Autoloader {}

interface php\AutoloaderClass extends php\Autoloader {
public function loadClass($name);
}

interface php\AutoloaderFunction extends php\Autoloader {
public function loadFunction($name);
}

interface php\AutoloaderConstant extends php\Autoloader {
public function loadConstant($name);
}

bool php\autoload_register(php\Autoloader $loader, $prepend);

The syntax provided in this RFC is a proposal. It's not set in stone. If
you don't like it, let's work towards a better one!

Thanks,

Anthony

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Anthony Ferrara]

Stas,

Moreover, since this replaces a simple hash lookup with additional two
> function calls (and also other operations included in those) everywhere
> in the engine, it will also have performance impact of one of the most
> frequently used operations in the engine - function calls - while
> providing absolutely no benefit for 100% of existing code and 99.99% of
> future code.
>

This was already directly covered in the RFC already:
https://wiki.php.net/rfc/function_autoloading#c_api_backwards_compatibility

Basically, two new macros are introduced which expand directly to hash
lookups.

#define ZEND_LOOKUP_FUNCTION_BY_NAME(name, name_length, fbc)
(zend_hash_find(EG(function_table), (name), (name_length) + 1,
(void**) (fbc)) == SUCCESS || zend_lookup_function((name),
(name_length), (fbc)) == SUCCESS)

So nothing changes from present (at all) unless a function is not defined.
Today, that's an error case. So the only performance change occurs if
zend_hash_find (which is already there) returns FAILURE. THEN the logic
which includes autoloading would run.

So no, there should be no performance impact at all to existing code thanks
to operator short circuiting.

Anthony

Re: [PHP-DEV] Re: Always set return_value_ptr?

[Pierre Joye]

hi,

On Fri, Aug 30, 2013 at 12:44 PM, Terry Ellison  wrote:

> Yes I understand that, but the code processes the elements in this dirname,
> basename, filename, extension order so the two statements are equivalent in
> implementation.
>
> I am an experienced developer but a newbie-ish to the PHP developer
> community, and I come back to my Q.  What do we typically do if we come
> across such weird functional behaviour outside the documented use of a
> standard function?
>
> * Shrug our shoulders and say "That's PHP for you.  BC rules"

As of now, this is the rule. BC has a much higher priority than some
weird edge cases bug fixes.

> * Fix the documentation to say what the code actually does

That should be the case as much as possible :)

> * Fix the code at the next major release, say 5.6 to have sensible error
> behaviour.

This is always a gray zone, especially if changes behaviors and then
introduces BC issues. BC breaks are the biggest problems in php.
Obviously I am not referring to new notices or warnings but actual
behaviors changes.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Always set return_value_ptr?

[Terry Ellison]

On 30/08/13 10:43, Julien Pauli wrote:
On Fri, Aug 30, 2013 at 2:30 AM, Terry Ellison 
mailto:ellison.te...@gmail.com>> wrote:



There's another one in string.c, in PHP_FUNCTION(pathinfo), that
could be applied as well, though there's little performance gain
in avoiding the copy of a 4 element string array.

BTW, looking at this pathinfo code, it doesn't do what the
documentation says it does -- or at least this states that the
optional argument if present should be _one_ of PATHINFO_DIRNAME,
PATHINFO_BASENAME, PATHINFO_EXTENSION or PATHINFO_FILENAME.
However, if a bitmask is supplied then this function returns the
element corresponding to the lowest bit value rather than an error
return, for example:

$ php -r 'echo pathinfo("/tmp/x.fred",
PATHINFO_FILENAME|PATHINFO_EXTENSION),"\n";'
fred

This is a bizarre behaviour.   At a minimum the documentation
should actually state what the function does. Or do we bother to
raise a patch to fix this sort of thing, given that returning an
empty string (or more consistently with other functions, NULL) in
this case could create a BC break with existing buggy code?


This is weird, yes.
It's not the lowest bit value that is returned, but the first element 
put in the array (as zend_hash_get_current_data() is used with no 
HashPosition) , which is even more confusing.


How to explain that in the documentation ? :|


Yes I understand that, but the code processes the elements in this 
dirname, basename, filename, extension order so the two statements are 
equivalent in implementation.


I am an experienced developer but a newbie-ish to the PHP developer 
community, and I come back to my Q.  What do we typically do if we come 
across such weird functional behaviour outside the documented use of a 
standard function?


* Shrug our shoulders and say "That's PHP for you.  BC rules"
* Fix the documentation to say what the code actually does
* Fix the code at the next major release, say 5.6 to have sensible error 
behaviour.


Just interested in understanding the consensus policy here.  Do I post a 
fix to the doc; post a fix to the code; or move on to other issues?


Regards Terry

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Pierre Joye]

On Fri, Aug 30, 2013 at 11:46 AM, Johannes Schlüter
 wrote:
> On Fri, 2013-08-30 at 10:49 +0200, Julien Pauli wrote:
>> Just to say : one benefit of this work would be to finally have autoload
>> functionnality (which is a Core feature IMO) included in Zend/ and no more
>> in an extension.
>
> What is the benefit, except having more stuff in the engine? SPL is part
> of the core. Let's not pack the engine with stuff not needed there.

Can we stop this madness of considering SPL as non standard or as a
'let put everything we don't know in there' extension?

It was created to provided some standard advanced functions or
structures. SPL was then used to work around some of the limitation of
the engine, or add features not desired by some of the core devs,
because no compromise was found. This must end, either it is needed
and should be in the engine, or it is not and can go in pecl. SPL is
standard, and always enabled. It should not continue to become a 2nd
layer to the engine but to provide advanced features like what it
initially did.

-- 
Pierre

@pierrejoye | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Johannes Schlüter]

On Fri, 2013-08-30 at 10:49 +0200, Julien Pauli wrote:
> Just to say : one benefit of this work would be to finally have autoload
> functionnality (which is a Core feature IMO) included in Zend/ and no more
> in an extension.

What is the benefit, except having more stuff in the engine? SPL is part
of the core. Let's not pack the engine with stuff not needed there.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Always set return_value_ptr?

[Julien Pauli]

On Fri, Aug 30, 2013 at 2:30 AM, Terry Ellison wrote:

> On 27/08/13 10:40, Nikita Popov wrote:
>
>> On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov 
>> wrote:
>>
>>  Hi internals!
>>>
>>> Is there any particular reason why we only pass return_value_ptr to
>>> internal functions if they have the ACC_RETURN_REFERENCE flag set?
>>>
>>> Why can't we always provide the retval ptr, even for functions that don't
>>> return by reference? This would allow returning zvals without having to
>>> copy them first (what RETVAL_ZVAL does).
>>>
>>> Motivation for this is the following SO question:
>>> http://stackoverflow.com/q/**17844379/385378
>>>
>>>  Patch for this change can be found here:
>> https://github.com/php/php-**src/pull/420
>>
>> The patch also adds new macros to allow easy use of this feature called
>> RETVAL_ZVAL_FAST/RETURN_ZVAL_**FAST (anyone got a better name?)
>>
>> If no one objects I'll merge this sometime soon.
>>
> +1 Though looking through the ext uses, most functions returning an array
> build it directly in return_value and thus avoid the copy.  I also see that
> you've picked up all of the cases in ext/standard/array.c where these
> macros can be applied.
>
> There's another one in string.c, in PHP_FUNCTION(pathinfo), that could be
> applied as well, though there's little performance gain in avoiding the
> copy of a 4 element string array.
>
> BTW, looking at this pathinfo code, it doesn't do what the documentation
> says it does -- or at least this states that the optional argument if
> present should be _one_ of PATHINFO_DIRNAME, PATHINFO_BASENAME,
> PATHINFO_EXTENSION or PATHINFO_FILENAME. However, if a bitmask is supplied
> then this function returns the element corresponding to the lowest bit
> value rather than an error return, for example:
>
> $ php -r 'echo pathinfo("/tmp/x.fred", PATHINFO_FILENAME|PATHINFO_**
> EXTENSION),"\n";'
> fred
>
> This is a bizarre behaviour.   At a minimum the documentation should
> actually state what the function does. Or do we bother to raise a patch to
> fix this sort of thing, given that returning an empty string (or more
> consistently with other functions, NULL) in this case could create a BC
> break with existing buggy code?
>

This is weird, yes.
It's not the lowest bit value that is returned, but the first element put
in the array (as zend_hash_get_current_data() is used with no HashPosition)
, which is even more confusing.

How to explain that in the documentation ? :|

Julien.Pauli

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Nikita Popov]

On Fri, Aug 30, 2013 at 6:57 AM, Stas Malyshev wrote:

> I think it is an unnecessary complication. Classes fit autoloader
> paradigm nicely, since the usual pattern is one class per one file
> (actually recommended in PSR), so it is easy to establish one-to-one
> automatic mapping between classes and files (also recommended in the
> PSR). But for functions nobody does this. This means that to implement
> function autoloader one will need to have a complicated and fragile
> logic (since there's no way to ensure this logic would be in sync with
> actual content of files containing multiple functions).
>

For functions people do not commonly use a one-to-one mapping between a
function name and a file, that's true. But there commonly *is* a one-to-one
mapping between a *namespace* and a file. So if you have a function
foo\bar\baz it will be in the file foo/bar.php (which defines all functions
of namespace foo\bar). I think this is a rather common pattern in
functional (or function-heavy) libraries and I use this myself too.

Apart from such a namespace-to-file mapping you can also use the same
approach some people use for classes: Just pregenerate the name-to-file
mappings in an array, then loop up from there (e.g. theseer/autoload). This
is one of the rare autoloading concepts that actually properly works in PHP
(much unlike PSR-0, which fails to honor case-insensitivity).


> Moreover, since this replaces a simple hash lookup with additional two
> function calls (and also other operations included in those) everywhere
> in the engine, it will also have performance impact of one of the most
> frequently used operations in the engine - function calls - while
> providing absolutely no benefit for 100% of existing code and 99.99% of
> future code.
>

I'd assume that this isn't yet the final patch and it will be improved to
make sure that there is no significant performance regression for function
calls not making use of autoloading. This should just be a matter of
inlining the part of the function with the direct hash lookup and avoiding
a duplicate lcname call. (Maybe in the engine just keep the old if
(zend_hash_find(...)) and add an else { autoload(); }.)

Putting autoloading of different entities into one function makes very
> little sense to me - why would the same code load both classes and
> functions?


I don't think it makes much sense to use the same function to autoload
classes and functions, but I think it makes sense to autoload both
functions and constants with the same mechanism, because presumably both
would follow the same naming-convention (e.g. the namespace-to-file mapping
mentioned above). So I think this is a useful feature and I definitely
don't see a reason why we need to explicitly prevent it.

Anyway, I'm +1 on this :) PHP has been neglecting it's functional sides.
The "use function" RFC and this one work on improving this a bit.

Nikita

Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]

[Remi Collet]

Le 30/08/2013 10:56, Jordi Boggiano a écrit :

> I think it'd be best to resolve this in PHP because otherwise it means
> Debian (& Fedora?) users will have the bad surprise of a quirky

Debian, Fedora, Mageia, Mandriva, Ubuntu, etc.

> implementation when deploying to prod, and I can imagine the
> impossible-to-reproduce issues that will follow.

This is clearly a important part of the proposal.
Having the same json implementation in "all" PHP.

Remi.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]

[Julien Pauli]

On Fri, Aug 30, 2013 at 10:56 AM, Jordi Boggiano  wrote:

> On 29.08.2013 09:52, Zeev Suraski wrote:
> > I have to say that I'm not wildly enthusiastic about making this change
> over
> > what appears to be a fairly minor comment in the license, and without
> even
> > going into the discussion as to why we want to promote Evil :)
> >
> > The main concerns I have are:
> > * Downwards compatibility.  We've found one potential issue, how can we
> > guarantee that there aren't others when we deal with a completely
> different
> > implementation?  I think that users that bump into apps suddenly
> breaking in
> > obscure edge cases will not be very understanding when we explain to them
> > that we did that over a licensing quirk - that I'm willing to bet they'll
> > say isn't applicable to them...
> > * Performance.  Again, for the same reasons, I think it'll be difficult
> for
> > us to defend this decision in this context as well.  We switched to a 2x
> > slower implementation over this?  Really?
> >
> > I think that a better alternative would be enabling ext/jsonc to take
> over
> > the ext/json symbol space so that people who care about the license
> issue,
> > and/or are interested in the extra features - will be able to take
> advantage
> > of it as a drop-in replacement.  Debian can come with this switch turned
> on.
>
> I think it'd be best to resolve this in PHP because otherwise it means
> Debian (& Fedora?) users will have the bad surprise of a quirky
> implementation when deploying to prod, and I can imagine the
> impossible-to-reproduce issues that will follow.
>

I would say, to stay in the pipe, that then it would be a Debian issue, not
a PHP one.


>
> That said, your last proposal of at least having a switch in php like
> --enable-evil-json sounds better than the current state. If we do have
> an equivalent implementation though we might as well throw away the
> existing one instead of keeping two IMO, but that's a detail.
>

Seems good.

Julien.Pauli

Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]

[Jordi Boggiano]

On 29.08.2013 09:52, Zeev Suraski wrote:
> I have to say that I'm not wildly enthusiastic about making this change over
> what appears to be a fairly minor comment in the license, and without even
> going into the discussion as to why we want to promote Evil :)
> 
> The main concerns I have are:
> * Downwards compatibility.  We've found one potential issue, how can we
> guarantee that there aren't others when we deal with a completely different
> implementation?  I think that users that bump into apps suddenly breaking in
> obscure edge cases will not be very understanding when we explain to them
> that we did that over a licensing quirk - that I'm willing to bet they'll
> say isn't applicable to them...
> * Performance.  Again, for the same reasons, I think it'll be difficult for
> us to defend this decision in this context as well.  We switched to a 2x
> slower implementation over this?  Really?
> 
> I think that a better alternative would be enabling ext/jsonc to take over
> the ext/json symbol space so that people who care about the license issue,
> and/or are interested in the extra features - will be able to take advantage
> of it as a drop-in replacement.  Debian can come with this switch turned on.

I think it'd be best to resolve this in PHP because otherwise it means
Debian (& Fedora?) users will have the bad surprise of a quirky
implementation when deploying to prod, and I can imagine the
impossible-to-reproduce issues that will follow.

That said, your last proposal of at least having a switch in php like
--enable-evil-json sounds better than the current state. If we do have
an equivalent implementation though we might as well throw away the
existing one instead of keeping two IMO, but that's a detail.

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] com php-src: Fixed bug #65564 stack-buffer-overflow in DateTimeZone stuff caught by AddressSanitizer: NEWS ext/date/php_date.c

[Remi Collet]

> Link:   
> http://git.php.net/?p=php-src.git;a=commitdiff;h=6fab1caa4100cf05fcf485ef0917830ae9f57563

What do you think to add the -fsanitize=address option (if available)
for the debug build ?

Note, this will make build / test slower.

Remi.



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Julien Pauli]

On Fri, Aug 30, 2013 at 3:23 AM, Anthony Ferrara wrote:

> All,
>
> I have created a new draft RFC implementing function and constant
> autoloading in master:
>
> https://wiki.php.net/rfc/function_autoloading
>
> All feedback is welcome.
>

Just to say : one benefit of this work would be to finally have autoload
functionnality (which is a Core feature IMO) included in Zend/ and no more
in an extension.

Julien.Pauli

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Sebastian Bergmann]

Am 30.08.2013 10:42, schrieb Julien Pauli:
> Perhaps is it also time to talk about this subject back and finally all
> agree on a default recommanded implentation of autoloading in PHP
> (internally supported) ?

 The only autoloader implementation that makes sense to me is to use a
 tool such as https://github.com/theseer/Autoload to generate the code.

 That being said, I do not thinkthat the PHP project should recommend a
 specific tool but rather the concept.

-- 
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Julien Pauli]

On Fri, Aug 30, 2013 at 9:35 AM, Sebastian Bergmann wrote:

> Am 30.08.2013 03:23, schrieb Anthony Ferrara:
> > All feedback is welcome.
>
>  Can we please get rid off the __autoload() function first before we
>  consider adding new functionality?
>

Huge +1 to start deprecating this feature, then completely remove it.


And to continue the discussion, I recall that we, as PHP contributors,
disagreed to include a PSR-0 compatible autoloader into Core.
So the argument of PSR-0 is not valid for me, as it has nothing to do with
PHP internals and actually is "just a recommandation" we didn't want to
merge into PHP.
Perhaps is it also time to talk about this subject back and finally all
agree on a default recommanded implentation of autoloading in PHP
(internally supported) ?

Julien.Pauli

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Sebastian Bergmann]

Am 30.08.2013 03:23, schrieb Anthony Ferrara:
> All feedback is welcome.

 Can we please get rid off the __autoload() function first before we
 consider adding new functionality?

-- 
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Sebastian Krebs]

2013/8/30 Stas Malyshev 

> Hi!
>
> > I have created a new draft RFC implementing function and constant
> > autoloading in master:
> >
> > https://wiki.php.net/rfc/function_autoloading
> >
> > All feedback is welcome.
>
> I think it is an unnecessary complication. Classes fit autoloader
> paradigm nicely, since the usual pattern is one class per one file
> (actually recommended in PSR), so it is easy to establish one-to-one
> automatic mapping between classes and files (also recommended in the
> PSR).


Autoloading was introduced long before PSR-0 and PSR-0 is also only a
recommendation. So saying "class autoloading was easily introduceable,
because there was _always_ a class<->file mapping" is somehow misleading.


> But for functions nobody does this. This means that to implement
> function autoloader one will need to have a complicated and fragile
> logic (since there's no way to ensure this logic would be in sync with
> actual content of files containing multiple functions).
>

This is the same complicated and fragile logik you need for class loading.
For example compared to PSR-0 functions could be implemented in a file
named after the namespace. An autoloader would be very similar to every
already existing PSR-0 class loader.


>
> Moreover, since this replaces a simple hash lookup with additional two
> function calls (and also other operations included in those) everywhere
> in the engine, it will also have performance impact of one of the most
> frequently used operations in the engine - function calls - while
> providing absolutely no benefit for 100% of existing code and 99.99% of
> future code.
>
> Putting autoloading of different entities into one function makes very
> little sense to me - why would the same code load both classes and
> functions? How would it do that besides ugly switch that just stuffs two
> completely different logic pieces into one function for no reason? The
> example given in the RFC is certainly not what anybody would actually
> want their autoloaders to do, so I fail to see any case for doing it and
> for putting loading more than one entity into one function (that given
> that autoloading function would be desirable at all, which it still
> doesn't seem so for me).


> It is
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
github.com/KingCrunch

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Sebastian Krebs]

2013/8/30 Stas Malyshev 

> Hi!
>
> > I disagree on the basis that namespaced functions/constants *do* fit the
> > same autoloading paradigm.
>
> If they're already namespaced, what prevents one to put it in a class
> and use good old PSR-compatible loading?
>

Well, static methods aren't the same as functions.


>
> > Those function calls would only kick in if the function/constant wasn't
> > already defined, which will be the exception case, so perf isn't a
> > strong argument.
>
> Not according to the code I see in the patch. There I see 2 func calls
> (among other things) before the hash is even looked up.


> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
github.com/KingCrunch

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Sara Golemon]

> If they're already namespaced, what prevents one to put it in a class
> and use good old PSR-compatible loading?
>
> Nothing, really... Just countering your specific premise.


> > Those function calls would only kick in if the function/constant wasn't
> > already defined, which will be the exception case, so perf isn't a
> > strong argument.
>
> Not according to the code I see in the patch. There I see 2 func calls
> (among other things) before the hash is even looked up.
>
> Well, the patch needs work obviously.  I'm living in a magical world where
that's already been fixed. :)

-Sara

Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading

[Stas Malyshev]

Hi!

> I disagree on the basis that namespaced functions/constants *do* fit the
> same autoloading paradigm.

If they're already namespaced, what prevents one to put it in a class
and use good old PSR-compatible loading?

> Those function calls would only kick in if the function/constant wasn't
> already defined, which will be the exception case, so perf isn't a
> strong argument.

Not according to the code I see in the patch. There I see 2 func calls
(among other things) before the hash is even looked up.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php