On Fri, Jul 25, 2014 at 11:54 AM, Matteo Beccati p...@beccati.com wrote:
On 23/07/2014 13:01, Dan Ackroyd wrote:
Regarding the change in behaviour, I think the patch
https://bugs.php.net/patch-display.php?bug=67064patch=bug67064-BCrevision=1402667581
should definitely be applied.
On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov nikita@gmail.com wrote:
On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye pierre@gmail.com wrote:
On Jul 27, 2014 8:17 PM, Lonny Kapelushnik lo...@lonnylot.com wrote:
On Jul 27, 2014, at 1:19 PM, Pierre Joye pierre@gmail.com wrote:
Hi,
On Mon, Jul 28, 2014 at 5:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion would be
nice
to have.
Currently, PHP module functions/classes/interfaces are using global(root)
namespace.
If it is changed to use its own
On 28/07/14 09:30, Ferenc Kovacs wrote:
On Fri, Jul 25, 2014 at 11:54 AM, Matteo Beccati p...@beccati.com wrote:
On 23/07/2014 13:01, Dan Ackroyd wrote:
Regarding the change in behaviour, I think the patch
Hi,
On Mon, Jul 28, 2014 at 10:33 AM, Pierre Joye pierre@gmail.com wrote:
On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov nikita@gmail.com wrote:
On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye pierre@gmail.com wrote:
On Jul 27, 2014 8:17 PM, Lonny Kapelushnik lo...@lonnylot.com wrote:
One must absolutely not be required to use
namespaces for everything.
+1
I fully share this statement as well.
Please, do not force any user to use namespaces.
PHP's never been namespace based, it added their support to 5.3.
IMO, PHP should never be namespace based for its own syntax.
On 28/07/14 03:44, David Dai wrote:
I can confirm that, wikimedia is migrating from PHP to HHVM, see:
http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077690.html
and I also have saw many friends talking about migrating from PHP to HHVM
only for performance gain.
That perhaps
On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion would be
nice
to have.
Currently, PHP module functions/classes/interfaces are using global(root)
namespace.
If it is changed to use its own
On 28 July 2014 09:22, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion would
be
nice
to have.
Currently, PHP module functions/classes/interfaces
On Mon, Jul 28, 2014 at 10:49 AM, Peter Cowburn petercowb...@gmail.com
wrote:
On 28 July 2014 09:22, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion
On Mon, Jul 28, 2014 at 9:33 AM, Pierre Joye pierre@gmail.com wrote:
On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov nikita@gmail.com
wrote:
On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye pierre@gmail.com
wrote:
On Jul 27, 2014 8:17 PM, Lonny Kapelushnik lo...@lonnylot.com
On 28 Jul 2014, at 03:58, Yasuo Ohgaki yohg...@ohgaki.net wrote:
If it is changed to use its own namespace, user space APIs may be changed
flexible and user controlled manner. Thus, PHP may have
- Consistent naming
- Consistent parameter order
- Graceful function/class/interface
On Mon, 28 Jul 2014, Ferenc Kovacs wrote:
I think it would make sense to announce that the php namespace is reserved
for internal use, but I don't think that we are ready for moving everything
under namespaces.
http://php.net/manual/en/userlandnaming.php could indeed do with some
updates!
On Sat, 26 Jul 2014, Lonny Kapelushnik wrote:
Morning all,
Previously I posted on the list requesting any immediate feedback on
this proposal. Given the quick feedback I received I’ve made an RFC
for deprecating and removing the imagettftext and imagettfbbox
functions:
Hello guys,
so... fgetss(). We have such a beautiful function in PHP. As it's
described in the manual: Get line from file pointer and strip HTML
tags. I'm wondering if it has any differences/advantages over using
just strip_tags(fgets($stream)).
I'm going to write an RFC proposing
On 28 Jul 2014, at 12:20, Derick Rethans der...@php.net wrote:
Though this is a small change I believe it will bring significant value
to the PHP community.
The only value removing functions brings is broken code. There are no
functional issues with the existing functions. Leave them
IMP, C89 is simple enough and reliable. Though it is old. it is wildly
supported.
On Jul 26, 2014, at 1:22 AM, David Soria Parra d...@php.net wrote:
On 2014-07-25, Andrea Faulds a...@ajf.me wrote:
On 25 Jul 2014, at 18:02, Nikita Popov nikita@gmail.com wrote:
I think the main
On 28 Jul 2014, at 12:41, Huqiu Liao liaohu...@gmail.com wrote:
IMP, C89 is simple enough and reliable. Though it is old. it is wildly
supported.
It is simple, reliable and widely-supported, sure, but it lacks certain
features that could be useful. In 2014, while not all compilers support
Hi everyone,
On 28/07/2014 09:46, Michael Wallner wrote:
https://bugs.php.net/patch-display.php?bug=67064patch=bug67064-BCrevision=1402667581
+1 on Matteo's patch. Rather a single fix than a couple.
IIRC, we also have to think about the count_elements handler.
I committed my patch locally
On Jul 28, 2014 1:23 PM, Andrea Faulds a...@ajf.me wrote:
On 28 Jul 2014, at 12:20, Derick Rethans der...@php.net wrote:
Though this is a small change I believe it will bring significant value
to the PHP community.
The only value removing functions brings is broken code. There are no
On Fri, 25 Jul 2014, Andrea Faulds wrote:
On 25 Jul 2014, at 18:02, Nikita Popov nikita@gmail.com wrote:
I think the main question here is whether MSVC will have good C99 support
by the time PHP-Next is released. The other major compilers (GCC, Clang,
Intel) may not support all of
On 28 Jul 2014, at 15:00, Derick Rethans der...@php.net wrote:
Well, we don’t need to allow all of C99. We can simply allow using
features that are widely supported and actually useful. For example,
declarations between statements,
I think that makes code a lot less readable, so I would
I think opinions about readability are subjective.
The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does not.
Breaking something without a real reason is not a good move.
Thanks. Dmitry.
On Mon,
On Jul 28, 2014 9:14 PM, Dmitry Stogov dmi...@zend.com wrote:
I think opinions about readability are subjective.
The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does
not.
We are working with the
On 28 Jul 2014, at 20:14, Dmitry Stogov dmi...@zend.com wrote:
The real problem, that it'll break compatibility with old uncommon compilers.
I'm not sure if new MSVC versions support it, but the one I use - does not.
Breaking something without a real reason is not a good move.
While C99
On Jul 28, 2014 10:13 PM, Andrea Faulds a...@ajf.me wrote:
On 28 Jul 2014, at 20:14, Dmitry Stogov dmi...@zend.com wrote:
The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does
not.
Breaking
PHP language spec
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
VCS Account Approved: joelm approved by bjori \o/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
发自我的 iPad
在 2014年7月28日，22:20，Andrea Faulds a...@ajf.me 写道：
On 28 Jul 2014, at 15:00, Derick Rethans der...@php.net wrote:
Well, we don’t need to allow all of C99. We can simply allow using
features that are widely supported and actually useful. For example,
declarations between
I support the move to C99... but not yet. We definitely need a longer
period for Visual Studio support; I suspect over time more compilers
will support C99 now that VC does.
More importantly I'd like to see any standard adherence to be more
strict so we can compile with -pedantic. Some of the big
If it is changed to use its own namespace, user space APIs may be changed
flexible and user controlled manner. Thus, PHP may have
- Consistent naming
- Consistent parameter order
- Graceful function/class/interface deprecation
(We know what we should do for these, right?)
I do not
发自我的 iPad
在 2014年7月28日，22:20，Andrea Faulds a...@ajf.me (mailto:a...@ajf.me) 写道：
On 28 Jul 2014, at 15:00, Derick Rethans der...@php.net
(mailto:der...@php.net) wrote:
Well, we don’t need to allow all of C99. We can simply allow using
features that are widely
On 25/07/14 17:37, Julien Pauli wrote:
We nowadays support C89 officially . It is very stable and well implemented
in almost every compiler nowadays, but it is old and lack some features we
could benefit from.
Isn't it interesting that on one hand we have a continual complaint that
PHP is
33 matches
Mail list logo
