From: Maciej Sobaczewski [mailto:msobaczew...@gmail.com]
>
> 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($s
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 ge
>
> 发自我的 iPad
>
> > 在 2014年7月28日，22:20，Andrea Faulds mailto:a...@ajf.me)> 写道：
> >
> >
> > On 28 Jul 2014, at 15:00, Derick Rethans > (mailto:der...@php.net)> wrote:
> >
> > > > Well, we don’t need to allow all of C99. We can simply allow using
> > > > features that are widely supported a
> 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
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
发自我的 iPad
> 在 2014年7月28日，22:20，Andrea Faulds 写道：
>
>
> On 28 Jul 2014, at 15:00, Derick Rethans 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 th
VCS Account Approved: joelm approved by bjori \o/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
PHP language spec
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Jul 28, 2014 10:13 PM, "Andrea Faulds" wrote:
>
>
> On 28 Jul 2014, at 20:14, Dmitry Stogov 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 with
On 28 Jul 2014, at 20:14, Dmitry Stogov 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 itself would,
On Jul 28, 2014 9:14 PM, "Dmitry Stogov" 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 vc team
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, Ju
On 28 Jul 2014, at 15:00, Derick Rethans 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 not be
On Fri, 25 Jul 2014, Andrea Faulds wrote:
>
> On 25 Jul 2014, at 18:02, Nikita Popov 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 C99 (esp stu
On Jul 28, 2014 1:23 PM, "Andrea Faulds" wrote:
>
>
> On 28 Jul 2014, at 12:20, Derick Rethans 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
> > functi
Hi everyone,
On 28/07/2014 09:46, Michael Wallner wrote:
>>> https://bugs.php.net/patch-display.php?bug=67064&patch=bug67064-BC&revision=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 lo
On 28 Jul 2014, at 12:41, Huqiu Liao 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 all of
C99, most s
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 wrote:
> On 2014-07-25, Andrea Faulds wrote:
>>
>> On 25 Jul 2014, at 18:02, Nikita Popov wrote:
>>
>>> I think the main question here is whether MSVC will have g
On 28 Jul 2014, at 12:20, Derick Rethans 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 alone.
Th
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 deprecat
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:
>
> https:/
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 28 Jul 2014, at 03:58, Yasuo Ohgaki 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 deprecation
> (We know
On Mon, Jul 28, 2014 at 9:33 AM, Pierre Joye wrote:
> On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov
> wrote:
> > On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye
> wrote:
> >>
> >> On Jul 27, 2014 8:17 PM, "Lonny Kapelushnik"
> wrote:
> >> >
> >> > On Jul 27, 2014, at 1:19 PM, Pierre Joye
> wrote
On Mon, Jul 28, 2014 at 10:49 AM, Peter Cowburn
wrote:
>
>
>
> On 28 July 2014 09:22, Ferenc Kovacs wrote:
>
>> On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki wrote:
>>
>> > Hi all,
>> >
>> > Since we have discussion for Next PHP, "PHP" namespace discussion would
>> be
>> > nice
>> > to have.
>>
On 28 July 2014 09:22, Ferenc Kovacs wrote:
> On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki 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(
On Mon, Jul 28, 2014 at 4:58 AM, Yasuo Ohgaki 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 namespace, u
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
>
> 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.
Hi,
On Mon, Jul 28, 2014 at 10:33 AM, Pierre Joye wrote:
> On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov wrote:
>> On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye wrote:
>>>
>>> On Jul 27, 2014 8:17 PM, "Lonny Kapelushnik" wrote:
>>> >
>>> > On Jul 27, 2014, at 1:19 PM, Pierre Joye wrote:
>>> >>
On 28/07/14 09:30, Ferenc Kovacs wrote:
> On Fri, Jul 25, 2014 at 11:54 AM, Matteo Beccati 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=67064&patch=bug67064-BC&revision=1402667581
Hi,
On Mon, Jul 28, 2014 at 5:58 AM, Yasuo Ohgaki 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 namespac
On Sun, Jul 27, 2014 at 9:47 PM, Nikita Popov wrote:
> On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye wrote:
>>
>> On Jul 27, 2014 8:17 PM, "Lonny Kapelushnik" wrote:
>> >
>> > On Jul 27, 2014, at 1:19 PM, Pierre Joye wrote:
>> >>
>> >>
>> >> However the idea to add yet other warnings/notices to
On Fri, Jul 25, 2014 at 11:54 AM, Matteo Beccati 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=67064&patch=bug67064-BC&revision=1402667581
> > should definitely be applied.
> >
> > Current
34 matches
Mail list logo
