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
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
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
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
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
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
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
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/
On Fri, Aug 30, 2013 at 9:35 AM, Sebastian Bergmann sebast...@php.netwrote:
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
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
On Fri, Aug 30, 2013 at 3:23 AM, Anthony Ferrara ircmax...@gmail.comwrote:
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
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
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:
*
On Fri, Aug 30, 2013 at 10:56 AM, Jordi Boggiano j.boggi...@seld.be 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
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
On Fri, Aug 30, 2013 at 6:57 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
On Fri, Aug 30, 2013 at 2:30 AM, Terry Ellison ellison.te...@gmail.comwrote:
On 27/08/13 10:40, Nikita Popov wrote:
On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov nikita@gmail.com
wrote:
Hi internals!
Is there any particular reason why we only pass return_value_ptr to
internal
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
On Fri, Aug 30, 2013 at 11:46 AM, Johannes Schlüter
johan...@schlueters.de 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
On 30/08/13 10:43, Julien Pauli wrote:
On Fri, Aug 30, 2013 at 2:30 AM, Terry Ellison
ellison.te...@gmail.com 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
hi,
On Fri, Aug 30, 2013 at 12:44 PM, Terry Ellison ellison.te...@gmail.com 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
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
Stas,
On Fri, Aug 30, 2013 at 12:57 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
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
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 :
?php namespace foo; bar(); ?
What autoload should be triggered?
foo\bar or bar?
Both are valid
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
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
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
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
On Fri, Aug 30, 2013 at 10:33 AM, Laruence larue...@php.net wrote:
On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov nikita@gmail.com
wrote:
Hi internals!
This RFC proposes to add a syntax for argument unpacking:
https://wiki.php.net/rfc/argument_unpacking
Basically, this is
On Sat, Aug 31, 2013 at 12:13 AM, Leigh lei...@gmail.com wrote:
On Aug 30, 2013 1:31 PM, Anthony Ferrara ircmax...@gmail.com 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
On Fri, Aug 30, 2013 at 10:29 AM, Rasmus Schultz ras...@mindplay.dk 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',
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
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
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
On Aug 30, 2013 1:31 PM, Anthony Ferrara ircmax...@gmail.com 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
On Fri, Aug 30, 2013 at 6:57 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
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
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
On Aug 30, 2013, at 10:25 AM, Stas Malyshev smalys...@sugarcrm.com 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
On Fri, Aug 30, 2013 at 7:10 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
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
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
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
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.
--
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
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
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:
On Fri, Aug 30, 2013 at 11:48 AM, Rasmus Schultz ras...@mindplay.dk 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
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.
On Fri, Aug 30, 2013 at 4:52 PM, Johannes Schlüter
johan...@schlueters.de 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
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
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.
On Fri, Aug 30, 2013 at 7:45 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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:
On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov nikita@gmail.com 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
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
On Fri, Aug 30, 2013 at 05:13:05PM +0100, Leigh wrote:
On Aug 30, 2013 1:31 PM, Anthony Ferrara ircmax...@gmail.com 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
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
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
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,
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
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
2013/8/30 jbo...@openmv.com 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
Am 30.08.2013 04:30, schrieb Yasuo Ohgaki:
On Thu, Aug 29, 2013 at 9:00 PM, Ángel González keis...@gmail.com wrote:
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.
The following psaudocode is self explained
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.
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
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,
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.
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
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
2013/8/31 Stas Malyshev smalys...@sugarcrm.com
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.
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 stdin, line 1
range(*a, *b)
^
SyntaxError:
Hi!
Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou linep...@gmail.com:
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
don't see a reason why one should explicitly disallow doing multiple
unpacks.
Because it makes very hard to understand what's going on and makes no
sense semantically.
On 30 August 2013 20:58, Marc Bennewitz p...@marc-bennewitz.de 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
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
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.
2013/8/31 Bob Weinand bobw...@hotmail.com
Hi!
Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou linep...@gmail.com:
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
don't see a reason why one should explicitly disallow doing multiple
unpacks.
Because it makes very hard to understand
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
Hi,
On 30 Aug, 2013, at 11:29 PM, Rasmus Schultz ras...@mindplay.dk 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',
Hi!
Am 31.8.2013 um 01:39 schrieb Stas Malyshev smalys...@sugarcrm.com:
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
Hi!
Am 31.8.2013 um 01:39 schrieb Lazare Inepologlou linep...@gmail.com:
2013/8/31 Bob Weinand bobw...@hotmail.com
Hi!
Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou linep...@gmail.com:
2013/8/30 Stas Malyshev smalys...@sugarcrm.com
don't see a reason why one should explicitly
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
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:
77 matches
Mail list logo
