Hi!
> But what is "properly prefixed"? Is there a list of reserved prefixes?
Yes, it's called the manual :)
> I agree. However, there are other "namespaces" which are not so
> special, especially for beginners, for instance, array_* and str_*. And
Adding something like strlen() in core now p
Stanislav Malyshev wrote:
>> Hmm, would you consider introducing a new function in the *global*
>> namespace to be a self-contained feature? I would not, because the
>
> Depends on the function. It it's properly prefixed and does not rely or
> disrupt anything else then yes. Otherwise, no.
But
Hi!
> Hmm, would you consider introducing a new function in the *global*
> namespace to be a self-contained feature? I would not, because the
Depends on the function. It it's properly prefixed and does not rely or
disrupt anything else then yes. Otherwise, no.
> function definition would change
Hi Nikita,
On Thu, Apr 2, 2015 at 6:11 AM, Stanislav Malyshev
wrote:
> > * htmlentities() with some encodings like EUC-JP throws "Only basic
> > entities substitution is supported for multi-byte encodings other than
> > UTF-8; functionality is equivalent to htmlspecialchars"
>
> This looks like
Stanislav Malyshev wrote:
>> The questions here are:
>> * will this code break any code running with PHP before that patch?
>> * does this code change the language in any way?
>
> OK, so I think there's a misunderstanding here. What you describing is
> exactly my position - enhancements that are
Hi!
> The questions here are:
> * will this code break any code running with PHP before that patch?
> * does this code change the language in any way?
OK, so I think there's a misunderstanding here. What you describing is
exactly my position - enhancements that are a) small and b)
self-contained
Hi!
> * htmlentities() with some encodings like EUC-JP throws "Only basic
> entities substitution is supported for multi-byte encodings other than
> UTF-8; functionality is equivalent to htmlspecialchars"
This looks like notice.
> * mysqli::next_result() if there is no next result throws "There
Hi,
Am 01.04.2015 um 22:36 schrieb Stanislav Malyshev:
>> Debian, Ubuntu and CentOS: ~21,23%
>>
>> (I assume here like Anthony that the installs matching a distribution
>> specific version always come from that distribution).
>
> Pretty big one, I'd say, but even with this one you only get 1/5. A
Hi!
> Debian, Ubuntu and CentOS: ~21,23%
>
> (I assume here like Anthony that the installs matching a distribution
> specific version always come from that distribution).
Pretty big one, I'd say, but even with this one you only get 1/5. Also,
as I said, it's very easy to take distro package and
Hi Trevor,
Am 01.04.2015 um 22:19 schrieb Trevor Suarez:
> Author of PR https://github.com/php/php-src/pull/1145 here.
>
> I'm really quite sorry. I didn't mean to create a mess here. I was just
> trying to contribute. :/
I am sorry I caused this mess by using your PR (or better: the
acceptance
> Thank you for the really helpful explanation!
> Now I understand the reasons but I don't have enough experience in C or the
> engine to make that possible.
> Would it be possible to support it in the first place only if the return
> type hints are already known by the engine?
If my memory is wor
Damn Gmail... I just top-posted. I'm going to go away for a while now...
On Wed, Apr 1, 2015 at 4:19 PM Trevor Suarez wrote:
> Author of PR https://github.com/php/php-src/pull/1145 here.
>
> I'm really quite sorry. I didn't mean to create a mess here. I was just
> trying to contribute. :/
>
> Un
Author of PR https://github.com/php/php-src/pull/1145 here.
I'm really quite sorry. I didn't mean to create a mess here. I was just
trying to contribute. :/
Unfortunately, whether or not an RFC was necessary for an addition like
this wasn't very clear. I'm an internals noob, so I simply tried to
On Wed, Apr 1, 2015 at 9:38 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > As I mentioned this wasn't something without precedence, but seeing how
> > Derick(ext/date lead author/maintainer) was explicitly against this
> > change, and there were no favorable response from the list I tend to
> > agree
Hi,
Am 01.04.2015 um 21:43 schrieb Stanislav Malyshev:
>> That is right and I think that is the reality we have to face: most
>> users use distro versions. They get a new version when they need to
>> upgrade their distro every few years.
>
> I'm not sure where you got this statistics from, but as
type-hint on overwrite it's fine but it's logically the same
(this previously was an E_STRICT).
http://3v4l.org/YdB8s - works fine (E_STRICT lower then php7@20150401)
http://3v4l.org/UDk0n - Fatal error: Declaration of Bar::setTest() must be
compatible with Foo::setTest($test): Foo
http:
Hi!
> And Derick wrote: (in http://markmail.org/message/ukwizupev32ld5tg)
> "I am against this addition, even though the patch looks OK." That is
> not "any objection from him except for small CS fixes" but I don't know
> what discussion happened off-list.
OK, I missed that one. I'll revert it th
Hi!
> That is right and I think that is the reality we have to face: most
> users use distro versions. They get a new version when they need to
> upgrade their distro every few years.
I'm not sure where you got this statistics from, but as I said, it is
very easy to make .rpm or .deb with source
Hi!
> As I mentioned this wasn't something without precedence, but seeing how
> Derick(ext/date lead author/maintainer) was explicitly against this
> change, and there were no favorable response from the list I tend to
> agree with the revert.
Derick reviewed that patch and I didn't see him even
Hi Stas,
Am 01.04.2015 um 21:19 schrieb Stanislav Malyshev:
> Hi!
>
>> I am sorry for the contributor but my example is
>> https://github.com/php/php-src/pull/1145
>> (DateTime::createFromImmutable() method) which was posted here on the
>> list, got three negative replies but was merged neverthel
Hi!
> For Imagick, the issue is that a SVG string was being generated with
> something like:
>
> sprintf(svg, "pos: %f %f", x, y);
Yeah that is a problem... Two ways I see to fix it:
1. Reset the locale before it and restore afterwards (non-TS and in
general may be problematic)
2. Use other form
On 1 April 2015 at 18:58, Stanislav Malyshev wrote:
> Hi!
Stanislav Malyshev wrote:
> Library should not assume it runs in C locale,
Because it is not thread-safe, it is not safe for libraries to alter the locale.
I can't see any workaround to make this 'just work' - when printf
cannot be relie
t it's logically the same
> (this previously was an E_STRICT).
>
> http://3v4l.org/YdB8s - works fine (E_STRICT lower then php7@20150401)
> http://3v4l.org/UDk0n - Fatal error: Declaration of Bar::setTest() must be
> compatible with Foo::setTest($test): Foo
> http://3v4l.org/AuO
Hi!
> This should be true for number formatting but it's not true for date
> format.
Yes, date format is not internationalized. There are a lot of fixed
formats, so this should not be much of a surprise. One just has to know
which ones aren't. And yes, handling transition between fixed and
locali
On 1 April 2015 at 18:27, Marc Bennewitz wrote:
>
> Functionality not related to locale should not be effected by this global
This is issue is that that the locale affects all of the C library
that use it, which includes printf();
> -> The following bug reports are valid bugs and should be res
Hi!
> I am sorry for the contributor but my example is
> https://github.com/php/php-src/pull/1145
> (DateTime::createFromImmutable() method) which was posted here on the
> list, got three negative replies but was merged nevertheless. I will not
> reproduce the arguments here but now the door for a
Am 01.04.2015 um 20:58 schrieb Stanislav Malyshev:
Hi!
https://bugs.php.net/bug.php?id=67127 - breaks DateTime
This looks like misunderstanding how float-to-string works. If you asked
it to put commas as decimal separator, don't be surprised it puts commas
as decimal separator.
This should
Hi
Am 01.04.2015 um 21:02 schrieb Stanislav Malyshev:
Hi!
- make strtoupper/strtolower etc. to work with ascii only
This would be a bad idea, however much better idea is to make *system*
case folding (i.e. methods, classes, etc.) use ascii-only. Which we
already mostly do (see zend_op
Hi!
> The encoding was just about re-using it. I wouldn't probably propose
> such constant if it was just for encoding (the main purpose is decoding
> though). I just thought that it could be a good idea to have some usage
> for encoder if it's added. It seemed to me better than just ignore it
> c
Hi!
>- make strtoupper/strtolower etc. to work with ascii only
This would be a bad idea, however much better idea is to make *system*
case folding (i.e. methods, classes, etc.) use ascii-only. Which we
already mostly do (see zend_operators.c it explains what's going on). Of
course, there
Hi!
> The short version of why we should do this is that setlocale breaks
> things. It is a process wide operation, that is not thread safe on
> most platforms. Although people use it to alter the way strings are
> output, it also breaks libraries that are assuming that they are
> running in a "C"
Hi,
On Wed, Apr 1, 2015 at 6:15 PM, Michael Wallner wrote:
>
> > On 01 04 2015, at 18:28, François Laupretre wrote:
> >
> >> De : Ferenc Kovacs [mailto:tyr...@gmail.com]
> >>
> >> I could accept any decision between holding off new features until next
> >> minor/major and allowing features expl
On Tue, Mar 31, 2015 at 9:44 PM, Rowan Collins
wrote:
> On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev <
> smalys...@gmail.com> wrote:
> >> This is a straw man as far as the points I made are concerned. I'm
> >> talking about the risk of switching from 5.5 to 5.6, which is pretty
> >low.
Hi Yasuo,
On Wed, Apr 1, 2015 at 3:30 AM, Yasuo Ohgaki wrote:
>
> There are too many options (4 options to be exact) for JSON to work safely
> under HTML context currently. If user would not like to loose int/float
> information, 6 options are needed. Number of options are better to be
> reduced,
.org/YdB8s - works fine (E_STRICT lower then php7@20150401)
http://3v4l.org/UDk0n - Fatal error: Declaration of Bar::setTest() must
be compatible with Foo::setTest($test): Foo
http://3v4l.org/AuOsr - HHVM works fine
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
Hi Stas
On Wed, Apr 1, 2015 at 7:58 AM, Stanislav Malyshev
wrote:
>
>
> > encode: all float values will be encoded as string
> > - re-using the constant for encoder makes sense if PHP creates JSON for
> > platform that support lower float type (e.g. C float) and the precision
> > loss is not acce
Am 01.04.2015 um 18:15 schrieb Dan Ackroyd:
Hi,
I'd like to get people's feedback for the idea of making setlocale be
either deprecated and to be removed eventually or just increasing the
warning level against people using it.
What if the system is configured with a different locale?
OK we co
All,
I've added a PR for this: https://github.com/php/php-src/pull/1213
Please review the implementation and the wording (as well as the behavior).
I plan on merging this on Friday if there is no objection (as it seems
the support has already been unanimous with no hesitation).
Thanks!
Anthony
I am looking into optimizing the fast_increment_function in
Zend/zend-operators.h for better performance on aarch64 systems by adding
some inline assembly that will reproduce what currently exists for x86_64
and i386 systems.
My main issue at the moment is understanding what occurs in the x86_64
a
On Wed, Apr 1, 2015 at 7:08 PM, Michael Wallner wrote:
>
> > On 01 04 2015, at 18:15, Dan Ackroyd wrote:
> >
> > Hi,
> >
> > I'd like to get people's feedback for the idea of making setlocale be
> > either deprecated and to be removed eventually or just increasing the
> > warning level against p
On Wed, Apr 1, 2015 at 6:28 PM, François Laupretre wrote:
> > De : Ferenc Kovacs [mailto:tyr...@gmail.com]
> >
> > I could accept any decision between holding off new features until next
> > minor/major and allowing features explicitly without going through an
> RFC, but I
> > want to have an exp
> On 01 04 2015, at 18:28, François Laupretre wrote:
>
>> De : Ferenc Kovacs [mailto:tyr...@gmail.com]
>>
>> I could accept any decision between holding off new features until next
>> minor/major and allowing features explicitly without going through an RFC,
>> but I
>> want to have an expli
> On 01 04 2015, at 18:15, Dan Ackroyd wrote:
>
> Hi,
>
> I'd like to get people's feedback for the idea of making setlocale be
> either deprecated and to be removed eventually or just increasing the
> warning level against people using it.
>
> The short version of why we should do this is tha
> De : Ferenc Kovacs [mailto:tyr...@gmail.com]
>
> I could accept any decision between holding off new features until next
> minor/major and allowing features explicitly without going through an RFC,
> but I
> want to have an explicit definition on what is allowed and how should the
> case-
> b
Hi,
I'd like to get people's feedback for the idea of making setlocale be
either deprecated and to be removed eventually or just increasing the
warning level against people using it.
The short version of why we should do this is that setlocale breaks
things. It is a process wide operation, that i
Is the last one really a strict? Sounds like it should be a warning to me.
Similar to when you for each over something not an array
On 1 Apr 2015 15:58, "Nikita Popov" wrote:
> On Wed, Mar 25, 2015 at 5:14 PM, Nikita Popov
> wrote:
>
> > On Sun, Mar 15, 2015 at 4:46 PM, Nikita Popov
> > wrote:
On Wed, Mar 25, 2015 at 5:14 PM, Nikita Popov wrote:
> On Sun, Mar 15, 2015 at 4:46 PM, Nikita Popov
> wrote:
>
>> Hi internals!
>>
>> To ensure we have no shortage of new RFC votes...
>>
>> https://wiki.php.net/rfc/reclassify_e_strict#vote
>>
>> Voting is open for ten days :)
>>
>
> RFC is
On Wed, Apr 1, 2015 at 1:23 PM, François Laupretre wrote:
> > De : Dennis Birkholz [mailto:den...@birkholz.biz]
> >
> > in my opinion all feature changes should go in the next X.Y version and
> > should require an RFC.
> > The reason is that "small self-contained changes" that get pulled in
> > w
> De : Dennis Birkholz [mailto:den...@birkholz.biz]
>
> in my opinion all feature changes should go in the next X.Y version and
> should require an RFC.
> The reason is that "small self-contained changes" that get pulled in
> without a discussion on internals and an RFC can easily lead to bad
> des
Hello,
Am 30.03.2015 um 12:04 schrieb Ferenc Kovacs:
> I know that our official release process allows that, but there are some
> reasonable arguments against doing that and this topic was brought up
> multiple times related to specific fixes.
> I have two open PRs like that:
> https://github.com/
committed into master.
Dan, please update the RFC accordingly.
Thanks. Dmitry.
On Wed, Apr 1, 2015 at 11:14 AM, Dmitry Stogov wrote:
>
>
> On Wed, Apr 1, 2015 at 4:31 AM, Dan Ackroyd
> wrote:
>
>> Hi Dmitry,
>>
>> Your approach is definitely a better one, and I have no objection to
>> it whats
On Wed, Apr 1, 2015 at 1:28 PM, Stanislav Malyshev wrote:
> Hi!
>
>> That one is rather easy to follow and disallow any kind of bully pushes.
>
> "Easy to follow" != "good to follow". I have no idea what you mean by
> "bully pushes".
>
>> Which years are you referring to?
>
> The ones that will pa
On 01/04/15 07:28, Stanislav Malyshev wrote:
> You may think if we ban
> enhancement then people would jump to 7.x in droves - but I have yet to
> see anybody taking decisions this way. So far statistics says people
> still are in 5.3 and 5.4 massively - though we do not add features there
> for qu
On Wed, Apr 1, 2015 at 4:31 AM, Dan Ackroyd wrote:
> Hi Dmitry,
>
> Your approach is definitely a better one, and I have no objection to
> it whatsoever.
>
Your patch was quite good. You just didn't know what this NULL return
required a hack in the PHP core :)
>
> Sorry, I was too busy to look
Hi!
> to utilize a binary search algorithm. Since the requirement for a binary
> search is that the array being searched is sorted, I thought is would be a
> good idea to have a Boolean parameter in the binary search function to
> specify if the input array should be sorted or not. something among
> -Original Message-
> From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Sent: Wednesday, April 01, 2015 10:12 AM
> To: Anthony Ferrara; Pavel Kouřil
> Cc: Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] Naming of 'weak' type hints
>
> Hi!
>
> > general. However as far as type de
Hi!
> general. However as far as type declarations are concerned, I think it
> would be fair to talk about the two modes as "coercive" and "strict".
I think this is a good option.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
57 matches
Mail list logo
