Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
> 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 disagree on the basis that namespaced functions/constants *do* fit the same autoloading paradigm. 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. > > 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. > 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 I agree with 100%. -Sara
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 12:58 PM, Stas Malyshev wrote: > Hi! > >> It is > > Oops, clicked too soon. I wanted to conclude that I think it is too many > complications in the engine for too little gain. I agree with Stas here. thanks > -- > 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 > -- 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
Hi! > It is Oops, clicked too soon. I wanted to conclude that I think it is too many complications in the engine for too little gain. -- 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
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). 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
Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions
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. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] [DRAFT] [RFC] Function autoloading
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] Re: Always set return_value_ptr?
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?
Regards
Terry
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Signature compatibility: Number of arguments
Hi! > I respectfully disagree. > > The first method requires at least one parameter (or two, depending on > the pending clarification in the other thread) , and the latest: zero > or more (or 1 or more). Yes, this is true. But how it is an objection? LSP allows to weaken preconditions, but not to strengthen them - that's exactly what happens. Any method call that worked for base class would also work for derived class, and some other, additional calls, would work too. >> Is it okay to change this? > > I see no reason to do so and I would say -0.5. The reason is that current situation does not match LSP requirements and serves no useful purpose. Especially the second one which literally has the same preconditions but for some weird reason is rejected. -- 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] Refactored magic methods
On Thu, Aug 29, 2013 at 5:59 PM, Levi Morrison wrote: > On Thu, Aug 29, 2013 at 5:00 AM, Nikita Popov wrote: > >> On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli wrote: >> >> > Hi internals. >> > >> > I started a work of refactoring magic methods from internals. >> > >> > The first goal was to never write ourselves things like "__get", but use >> > macros for those names. (get, set, invoke, etc...). >> > >> > A second goal was to rewrite some parts of the compiler which looked >> like >> > code duplication which could benefit from macro refactoring. >> > >> > I did that. >> > All tests pass. >> > >> > It may look uglier for people who dont like having more macros, but >> anyway, >> > we can cherry pick some commits, etc... >> > >> > If you have ideas or things to say, I'm listening. >> > https://github.com/jpauli/php-src/compare/macroing >> > >> >> I'm not really a fan of heavy macro usage, so here an alternative >> suggestion: >> >> >> >> https://github.com/nikic/php-src/commit/375bd7911fd117696b8b5d63c104fd588d69c409 >> >> Basically, instead of going through all the magic methods manually we >> define a structure holding information on magic methods and then loop >> through it doing generic checks. >> >> The above example only changes zend_check_magic_method_implementation, but >> the idea can be generalized to the other occurances of magic method checks >> (making the structure a global constant so they can all make use of the >> information in there.) >> >> Nikita >> > > I think I like Nikita's version better. Fewer macros are nicer in my > opinion. > I like yes, I think we can mix both by having a global containing all magic method infos, and some macros to use them. I'll propose another patch based on that ;-) Thank you, Julien.Pauli
Re: [PHP-DEV] Refactored magic methods
On Thu, Aug 29, 2013 at 5:00 AM, Nikita Popov wrote: > On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli wrote: > > > Hi internals. > > > > I started a work of refactoring magic methods from internals. > > > > The first goal was to never write ourselves things like "__get", but use > > macros for those names. (get, set, invoke, etc...). > > > > A second goal was to rewrite some parts of the compiler which looked like > > code duplication which could benefit from macro refactoring. > > > > I did that. > > All tests pass. > > > > It may look uglier for people who dont like having more macros, but > anyway, > > we can cherry pick some commits, etc... > > > > If you have ideas or things to say, I'm listening. > > https://github.com/jpauli/php-src/compare/macroing > > > > I'm not really a fan of heavy macro usage, so here an alternative > suggestion: > > > > https://github.com/nikic/php-src/commit/375bd7911fd117696b8b5d63c104fd588d69c409 > > Basically, instead of going through all the magic methods manually we > define a structure holding information on magic methods and then loop > through it doing generic checks. > > The above example only changes zend_check_magic_method_implementation, but > the idea can be generalized to the other occurances of magic method checks > (making the structure a global constant so they can all make use of the > information in there.) > > Nikita > I think I like Nikita's version better. Fewer macros are nicer in my opinion.
Re: [PHP-DEV] Re: Signature compatibility: Number of arguments
I think of the following definition: function foo($bar = NULL) To really be two definitions with method overloading: > function foo() function foo($bar) Allowing an inheritor/implementor to choose to not implement the second signature does not seem logical at all when you think of them this way. I'm against this this proposal.
[PHP-DEV] Re: handling non-fatal compile-time errors
On Thu, Aug 8, 2013 at 5:11 PM, Ferenc Kovacs wrote: > Hi, > > I've just bumped into https://bugs.php.net/bug.php?id=65322 recently, and > I would like you get some opinions on the issue. > Personally I think that it is a really bad design to introduce > pedantic(E_STRICT) errors which can break basic functionality of the engine > (calling the registered autoloader), so if there is no viable solution to > make the autoloader work for these kind of errors, I would like to propose > removing the offending errors and make it a rule to not add compile-time > non-fatal errors until the problem is resolved. > > ps: on a related note, somehow I got the feeling that Lester complaining > that E_STRICT errors fataling/crashing the application migrated to PHP 5.4 > was related to this problem, and I'm a bit sad that we didn't managed to > figure this out back then. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > for the record this is a known(as reported) since 2007: https://bugs.php.net/bug.php?id=42098 and reported again in 2011: https://bugs.php.net/bug.php?id=54054&edit=2 do we agree with the resolution from the 2007, eg. it is fine that there an undefined list of errors (from all and any error level) which behave differently than most others (as it won't trigger the autoloader) and even an E_STRICT error can blow up a reasonably written application (an expected error occurs, which happens to be compile time, which will trigger the autoloader, which will fail to autoload it's dependencies, which will generate class not found fatal error). I expect much more similar reports now that people start to migrate to 5.4/5.5 where E_STRICT is part of E_ALL(and that the error reporting infrastructure in an average application is more likely to depend on autoloading nowadays). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
RE: [PHP-DEV] [RFC] Syntax for variadic functions
Lester's position seems unclear but I'll weigh-in. Having strict interfaces and arguments means that the developer does not have to parse and validate each parameter that is arbitrarily passed in. If anything, I would prefer to see func_get_args() removed entirely. Now, I know that won't happen but I don't think extending the associated functionality to be more vague is a good choice. -Original Message- From: Lester Caine [mailto:les...@lsces.co.uk] Sent: Thursday, August 29, 2013 7:52 AM To: PHP internals Subject: Re: [PHP-DEV] [RFC] Syntax for variadic functions Nikita Popov wrote: > I'd like to propose an RFC, which adds dedicated syntax for variadic > functions: > > https://wiki.php.net/rfc/variadics I can remember in PHP4 days, passing parameters to the database as a string of variables was the norm. Then arrays came along and it was preferable to pass the query followed by an array of values. We could take the array and validate the data in a function, adding any missing values needed before processing the SQL. Going back to the cumbersum method of working just seems wrong? Surely we should be promoting a tidier method of working? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- 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] Attitude against distributions... (Was: JSON non-free license)
Ondřej Surý wrote: Well, basically the pecl-json-c is now a default provider of JSON extension in Debian (and Fedora) and the downstream distributions (Ubuntu, RHEL, ...). This is an area I've highlighted in the past ... While the PHP distributions define a 'core' set of modules, I don't know of any Linux distribution that actually duplicates it? I'm always having to check which 'modules' are loaded as many of what is called 'core' are not loaded by default. And that does not even get as far as adding pecl modules and in some cases how adding pear ones are handled. The system has been broken for a long time, and it is getting more and more difficult to ensure that larger projects work 'out of the box'. Normally you have to say 'x is not loaded', and then make a guess at how that can be fixed on the particular distribution? And when ISP's are providing the PHP on shared hosting it's flavoured by the Linux distribution defaults. In the past I've asked for better support for the modular approach rather than simply assuming everything 'core' is always compiled in. Handling this comes in that category and while in this particular case it would be optimal that both versions work identically, something is going to be broken or 'improved'? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] Importing namespaced functions
Hey internals, The two weeks of voting have passed. Voting is now closed. The result of the vote is: 16 "Yes" votes, 4 "No". This translates to 16/20 = 0.8, which is above the required 2/3 majority threshold. As such, I consider this RFC accepted. Thanks for the feedback and support. Both Stas and Nikita pointed out some unhandled edge cases. I will work on resolving those before the patch can be merged, and will ask for another final review once I consider it ready. No significant changes will be needed, so I don't think extending the vote period is necessary. Please let me know if that is not acceptable, in which case it can be extended. Regards, Igor On Aug 15, 2013, at 4:08 PM, Igor Wiedler wrote: > Hello internals, > > About 3 weeks have passed since I announced the use_function RFC. A number of > issues were raised, and I believe all of them have been resolved at this > point. I would like to initiate the voting phase. > > RFC: https://wiki.php.net/rfc/use_function > Patch: https://github.com/php/php-src/pull/388 > > * The vote is on the implementation, so please check the patch. > * Since this is changing the language, it will need a 2/3 majority to be > accepted. > * The voting period ends in 2 weeks: on August 29th at 14.00 GMT. > > Cheers, > > Igor > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
On Thu, Aug 29, 2013 at 11:03 AM, Stas Malyshev wrote: > So if something is a question which needs > discussion, it is proper to raise it to the list, that doesn't mean > automatically it's considered not important or not worth fixing - quite > the contrary, raising it on the list makes sure more people are aware of > it and can participate in solving it. Ok, point taken. > > The "non-free" part of the archive is only a last resort solution. When > you > > move something to non-free, you also need to move any package that > > depends into a contrib part of the archive, and that would be much worse > > than replacing embedded json extension with the pecl that Remi wrote. > > Could you describe the reasons why it would be much worse? I.e. how the > user experience changes, what additional actions, if any, users would > have to do, etc.? Snippet from Debian Developers manual: > Packages which do not conform to the DFSG are placed in the non-free section. These packages are *not considered as part of the Debian distribution*, though we enable their use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. Also non-free (and contrib) are not enabled by default (I think), so people would have to modify their apt/sources.lists to enable the extra archive. Any package depending on php5 would have to be moved to the contrib/ section (again not enabled by default), e.g. every packaged extension and every packaged web app. That's simply not going to fly just because of JSON extension. It could happen only if you have relicenced whole PHP under some non-free license and were not willing to relicense it back (but I think in this case somebody would fork PHP as it happened to some other big projects before - f.e. XFree86 vs Xorg). And I even don't want to imagine the scale of the fallout from such transfer from main to non-free for PHP. I am asking this because right now as far as I can see > while json-c is in good shape, it has certain performance issues and > compatibility issues. I hope they would be fixed, but I think we need to > have all the options laid out before us to evaluate. Well, basically the pecl-json-c is now a default provider of JSON extension in Debian (and Fedora) and the downstream distributions (Ubuntu, RHEL, ...). And I don't even know if Fedora has similar place to put non-free packages. O. -- Ondřej Surý Have you tried Knot DNS – https://www.knot-dns.cz/ – a high-performance authoritative-only DNS server
Re: [PHP-DEV] [RFC] Syntax for variadic functions
Nikita Popov wrote: I'd like to propose an RFC, which adds dedicated syntax for variadic functions: https://wiki.php.net/rfc/variadics I can remember in PHP4 days, passing parameters to the database as a string of variables was the norm. Then arrays came along and it was preferable to pass the query followed by an array of values. We could take the array and validate the data in a function, adding any missing values needed before processing the SQL. Going back to the cumbersum method of working just seems wrong? Surely we should be promoting a tidier method of working? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Syntax for variadic functions
On Thu, Aug 29, 2013 at 12:09 AM, Stas Malyshev wrote:
> Hi!
>
> I like the idea, the concept of capturing "rest of args" is pretty
> common. But couldn't we in addition have func_get_args() be able to
> receive an int argument that would produce "the rest" in an easier way
> for those that prefer func_ger_args()?
>
I would do that if this RFC doesn't pass, but I don't see much point doing
both things (syntax + extra arg). Are there any particular scenarios where
using func_get_args() would be preferable?
> For prototype checks, this:
>
> public function query($query, ...$params);
> public function query($query, $param = null, ...$params);
>
> Should be compatible.
It already is. Only requirement is that the typehint/by-ref-mode of
$param=null is compatible with the typehint/by-ref-mode of ...$params :)
> Same with:
>
> public function query($query, ...$params);
> public function query($query);
>
> functions should be able to ignore some arguments, especially ones that
> are optional anyway. I also think this:
>
> public function query($query, ...$params)
> public function query(...$params)
>
> should be legal too.
>
I would like to stay consistent with the normal PHP behavior here. PHP
currently doesn't allow leaving off (required or optional) parameters. I
created a separate thread regarding that issue:
http://markmail.org/message/ejgmqjnjnbmfnuzv If we decide to allow having
less parameters there, then I'll follow suit here as well.
> I think it should also be explicitly specified what $params is if there
> is no arguments - null? false? array()? I'd probably prefer array as it
> makes it easy to do something like:
>
> public __construct(...$params) {
> foreach($params as $k => $v) { $this->$k = $v; }
> }
>
> but in any way it should be specified.
>
Now specified in
https://wiki.php.net/rfc/variadics#population_of_variadic_parameter: The
default is an empty array.
Thanks for the comments,
Nikita
Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions
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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Signature compatibility: Number of arguments
2013/8/29 Nikita Popov : > Hi internals! > > This is a spinoff from the variadics thread. Quoting Stas: > >> I also think this: >> public function query($query, ...$params) >> public function query(...$params) >> should be legal too. I respectfully disagree. The first method requires at least one parameter (or two, depending on the pending clarification in the other thread) , and the latest: zero or more (or 1 or more). > This is a general issue in PHP that we might want to fix: Currently a > method A is not compatible with a method B if A has less arguments than B. > > E.g. both of the following are incompatible signatures: > > public function foo($bar) > public function foo() > > public function foo($bar = NULL) > public function foo() > > This doesn't really make sense. Removing parameters doesn't violate LSP, > because in PHP it is legal to pass more arguments than declared. (Only > adding additional required parameters would violate LSP.) > > Is it okay to change this? I see no reason to do so and I would say -0.5. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Syntax for variadic functions
2013/8/28 Nikita Popov :
> Hi internals!
>
> I'd like to propose an RFC, which adds dedicated syntax for variadic
> functions:
>
> https://wiki.php.net/rfc/variadics
>
> Basically this allows declaring variadics directly in the function
> signature, rather than fetching the arguments using func_get_args().
> Example:
>
> public function query($query, ...$params) { /* ... */ }
>
> What are your thoughts on this?
>
> Thanks,
> Nikita
Using the current variadic functions makes it possible to use 0 or N
arguments, e.g.:
function sum() {
return array_sum(func_get_args());
}
echo sum(10, 5); // echoes 15
echo sum(); // echoes 0
I see nowhere in the RFC whether:
function sum(...$params) { /* */ }
Requires at minimum one argument or none.
I have the _feeling_ that you imply it's minimum one which I would
consider a bit inconsistent with the current "implementation".
Can you please clarify this Nikita?
Thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Refactored magic methods
On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli wrote: > Hi internals. > > I started a work of refactoring magic methods from internals. > > The first goal was to never write ourselves things like "__get", but use > macros for those names. (get, set, invoke, etc...). > > A second goal was to rewrite some parts of the compiler which looked like > code duplication which could benefit from macro refactoring. > > I did that. > All tests pass. > > It may look uglier for people who dont like having more macros, but anyway, > we can cherry pick some commits, etc... > > If you have ideas or things to say, I'm listening. > https://github.com/jpauli/php-src/compare/macroing > I'm not really a fan of heavy macro usage, so here an alternative suggestion: https://github.com/nikic/php-src/commit/375bd7911fd117696b8b5d63c104fd588d69c409 Basically, instead of going through all the magic methods manually we define a structure holding information on magic methods and then loop through it doing generic checks. The above example only changes zend_check_magic_method_implementation, but the idea can be generalized to the other occurances of magic method checks (making the structure a global constant so they can all make use of the information in there.) Nikita
[PHP-DEV] Re: Signature compatibility: Number of arguments
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov wrote: > This is a general issue in PHP that we might want to fix: Currently a > method A is not compatible with a method B if A has less arguments than B. > > E.g. both of the following are incompatible signatures: > > public function foo($bar) > public function foo() > > public function foo($bar = NULL) > public function foo() > > This doesn't really make sense. Removing parameters doesn't violate LSP, > because in PHP it is legal to pass more arguments than declared. (Only > adding additional required parameters would violate LSP.) > > Is it okay to change this? > > Thanks, > Nikita > Patch for this change: https://github.com/php/php-src/pull/424 Nikita
[PHP-DEV] Signature compatibility: Number of arguments
Hi internals! This is a spinoff from the variadics thread. Quoting Stas: > I also think this: > public function query($query, ...$params) > public function query(...$params) > should be legal too. This is a general issue in PHP that we might want to fix: Currently a method A is not compatible with a method B if A has less arguments than B. E.g. both of the following are incompatible signatures: public function foo($bar) public function foo() public function foo($bar = NULL) public function foo() This doesn't really make sense. Removing parameters doesn't violate LSP, because in PHP it is legal to pass more arguments than declared. (Only adding additional required parameters would violate LSP.) Is it okay to change this? Thanks, Nikita
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
Hi! > Unfortunatelly nobody pointed out that it has to be discussed in the mailing > list in the mentioned bug report. We have stated that we have a problem > with JSON license and we had to solve the problem we had. > I consider the licensing issue as a bug and it's always better to track it > as issue, but I get it that our views differ. Please don't misunderstand me, it's not a question of how important it is and I don't question that it is very important for you. I'm just saying if it's in the bug DB, most people won't see it, because bug db has literally thousands of reports and next to nobody reads every one of them and all the discussions there unless they are a) asked to by somebody, b) maintain extensions against which the bug is filed or c) performing community service by going through bug DB and looking for things they could fix. Or they randomly notice the discussion on the bugs list. But it is very easy to miss it, and the bug db is not made for discussing issues - it is made for tracking and fixing them, and people treat it accordingly. So if something is a question which needs discussion, it is proper to raise it to the list, that doesn't mean automatically it's considered not important or not worth fixing - quite the contrary, raising it on the list makes sure more people are aware of it and can participate in solving it. > The "non-free" part of the archive is only a last resort solution. When you > move something to non-free, you also need to move any package that > depends into a contrib part of the archive, and that would be much worse > than replacing embedded json extension with the pecl that Remi wrote. Could you describe the reasons why it would be much worse? I.e. how the user experience changes, what additional actions, if any, users would have to do, etc.? I am asking this because right now as far as I can see while json-c is in good shape, it has certain performance issues and compatibility issues. I hope they would be fixed, but I think we need to have all the options laid out before us to evaluate. -- 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] Attitude against distributions... (Was: JSON non-free license)
2013/8/28 Stas Malyshev : > Hi! > >> And while the issue was first reported by Debian, the other >> distributions share the same concerns. This is why PHP should consider >> this - because the other parts of the eco-system are already going >> forward with this. > > What we need to consider this extension as a replacement for core JSON is: > - explanation of advantages and disadvantages (noting that for most PHP > users "weird license" is not a significant disadvantage of the > extension) of the change > - RFC > - API description > - potential BC problems > - performance impact - and resources! (Maybe a Debian guy that cares a lot about this could help? Because that's the biggest issue, most of the time.) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
On Wed, Aug 28, 2013 at 8:50 PM, Stas Malyshev wrote: > Hi! > > > I would like to react on Stat's "it's-not-our-problem" comment in > > https://bugs.php.net/bug.php?id=63520 > > I assume by "Stat" you mean myself, though I'm not the only one who > Yup, sorry for mangling your name, this must be a result of me installing SPSS and analyzing some data in the same time :) > expressed the same sentiment of questioning why this is submitted as a > "bug" in PHP. Assuming that, below are my thoughts on the subject (I > apologize in advance for the length). > > > > > I am very sad to see a core developer take such a passive-aggressive > stance > > against distributions' problems. My wild guess would be that most of the > > users use the PHP in the pre-packaged form. Thus we really need to work > > together and not fight against each other even though the set of the > > problems (and their solutions) each party solves is different. > > I assure you that by raising this question I meant no aggression or > animosity toward anybody, but I do have a question of priorities here. Ok, point taken. Sorry for jumping to conclusions to early. > I understand that Debian has certain ideological guidelines which preclude > them from distributing certain software that does not fit their views on > how software should be licensed. Even though as far as I know Debian has > "non-free" area in which they distribute software with licenses other > than approved by Debian's guidelines, but ultimately I recognize that > the decision of what to distribute and what not is Debian's and their > alone. However, what happens in PHP project is decided by PHP developers > community and should gain consensus and acceptance in the community. > I would like to point out that it's not just the "Debian" (and other distributions) that has problem with JSON (non-free) license. If you look at the JSON presentation (link is somewhere in the FUD article) you will see the JSON author to mock IBM for giving them permission to use JSON for evil. (Also note the motivation – he did it to contribute to War on Terror, and I only can wish that it was ment as a joke, but I am afraid it wasn't. But I can never understand this whole concept anyway...) However, given all that, I think the matter would be handled better if, > before taking decisions that can influence many users of PHP that chose > to trust Debian to deliver their PHP builds, Debian would consult with > PHP community on how to handle that. I do not remember this question > being raised on PHP list and discussed there. Unfortunatelly nobody pointed out that it has to be discussed in the mailing list in the mentioned bug report. We have stated that we have a problem with JSON license and we had to solve the problem we had. > I personally found about > this decision by reading panic posts in the blogs along the line of "PHP > removes JSON support", which I do not think is the best outcome we could > hope for. I am sorry that it ended in a shitstorm by ignorant people, who are unable to _ask_ before they write bullshit, but I am not sure if we can prevent that. > I think PHP bug database is neither appropriate nor suitable > forum for discussing such things - it is meant for tracking bugs in PHP > code, e.g. mistakes made while implementing certain functionalities, and > the license of JSON code, which obviously being controversial and > causing issues for Debian, is definitely not there by any mistake and > should not be treated as "bug". It should be treated as licensing issue > and as such raised on this list and discussed and handled appropriately. > I consider the licensing issue as a bug and it's always better to track it as issue, but I get it that our views differ. > I certainly and wholeheartedly agree that we do need to work together > with distributions and that it would benefit our users. As a good start, > I would ask Debian representatives to work with PHP community within > processes accepted by the community, i.e. explain on this list why it is > impossible to distribute PHP the way it was distributed before for > years, why it is impossible to fit this code withing any "non-free" > framework Debian has, what Debian suggests to do (taking into account > this will influence wider PHP users community, many of whom, however > regrettable may it be, do not use Debian) and so on, initiating the > discussion that hopefully would come to some conclusion that would be > satisfactory to everyone involved. > The "non-free" part of the archive is only a last resort solution. When you move something to non-free, you also need to move any package that depends into a contrib part of the archive, and that would be much worse than replacing embedded json extension with the pecl that Remi wrote. Basically the "non-free" was created to circumvent the US crypto export restrictions (the machine was hosted outside US) and not as a solution to license problems in _core_ packages create
[PHP-DEV] stream_get_contents does not like stream wrapper
Hi internal, I have met a strange behavior with stream_get_contents and stream wrapper. This is explained here: https://bugs.php.net/65581. Thoughts? -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- 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]
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. My 2c. Zeev > -Original Message- > From: Remi Collet [mailto:r...@fedoraproject.org] > Sent: Thursday, August 29, 2013 8:55 AM > To: PHP Internals > Subject: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion] > > Subject: Switch from json extension which have a problematic (non-free) > license to jsonc dropin free alternative. > > RFC: https://wiki.php.net/rfc/free-json-parser > > > > Remi. > > -- > 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] Switch from json extension to jsonc [Discussion]
Le 29/08/2013 09:04, Stas Malyshev a écrit : > Hi! > >> From my analysis (profiling), most of the time is spent in memory >> allocation calls. >> >> As we used a parser from a library, we do >> 1- parse in library space >> 2- object tree allocation of the result >> 3- copy result from library space to php space >> 4- PHP object tree allocation > > Can't we just patch the lib to do the right thing? Is it just malloc vs. > emalloc or deeper problems? Probably deeper problem. Moving to statically allocated stack (just a stupid test, of course) of json_object only reduce time by ~15%... > >> I don't see any good solution to optimize this except copying the code >> from the library into PHP, and thus remove stop 2+3. > >> Of course I have tried to avoid this (copying the code) and prefer to >> keep the library unchanged... but... > > Well, 2x slowdown is pretty serious. I didn't have a good look at the > code so I can't advise how to fix it, but I think it needs to be fixed > one way or another. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
