Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-16 1:27 GMT+02:00 Lester Caine : > None of the listed bugs are a problem in normal use. Some WERE fixed in > previous code, but those fixes were not merged with the master code base > in pre git days :( So you are saying that in your patch for the PHP7 support for

Re: [PHP-DEV] [RFC] orphan extensions cleanup

Hi Stas, On Aug 15, 2016 11:50 PM, "Stanislav Malyshev" wrote: > > Hi! > > >> enchant: > >> I thought Pierre maintained enchant? Despite it haven't had much real > >> activity for years > > > > Well there are not much changes in the api. > > > > And it works. So -1 here. > >

Re: [PHP-DEV] [RFC] orphan extensions cleanup

On 15/08/16 23:50, Kalle Sommer Nielsen wrote: > The problem that we are trying to solve here is that there is no one > to maintain those ways we have right now to collect to > Interbase/Firebird, how are we magically gonna provide some decent > alternatives if there is no one to even work on what

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-16 0:07 GMT+02:00 Lester Caine : > https://www.mail-archive.com/internals@lists.php.net/msg82170.html From > December last year. *I* was under the impression that it was this work > that was in the driver already after we had helped debug it! >

Re: [PHP-DEV] [RFC] orphan extensions cleanup

Hi Adam 2016-08-15 23:34 GMT+02:00 Adam Baratz : > As one of those two people, it would help to have an official maintainer for > this extension. The path for "something's broken" or "something should be > different" to "committed fix" has been pretty murky. First of all,

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

Hi Yasuo 2016-08-16 0:00 GMT+02:00 Yasuo Ohgaki : > Many people concern about BC. It's reasonable. > How about document deprecation of them now? And not mention when they > will be removed. It may exist for long, but users are better to use generic > encoding conversion

Re: [PHP-DEV] [RFC] orphan extensions cleanup

On 15/08/16 18:48, Kalle Sommer Nielsen wrote: > 2016-08-15 19:09 GMT+02:00 Lester Caine : >> We will do what WE have to to maintain it, but none of us are up to >> speed with current PHP 'style' of coding so we also need help which is >> how we managed to get the PHP7 version

[PHP-DEV] Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

Hi all, On Mon, Aug 15, 2016 at 12:17 PM, Yasuo Ohgaki wrote: > utf8_decode() and utf8_encode() are not needed and causing problems > than solving. > > https://wiki.php.net/rfc/remove_utf_8_decode_encode > > Proposal > - Document deprecation them now > - Remove them from

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

On Tue, Aug 16, 2016 at 6:39 AM, Yasuo Ohgaki wrote: > Do you still sure "There will be no collisions at all"? Do you still think it's sure "There will be no collisions at all"? -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

On Tue, Aug 16, 2016 at 5:21 AM, Tom Worster wrote: > On 8/14/16 4:13 PM, Yasuo Ohgaki wrote: > >> "Now assume a 128 bit session identifier that provides 64 bits of >> entropy. > > > What exactly does this mean? When you have random 128 bits value, it does not mean it has full

[PHP-DEV] Re: [RFC] orphan extensions cleanup

Hi! > Maybe it would be better to first check the current status quo of > maintainership, and after that taking care of the insufficiently > maintained extensions. I think we can do both in parallel. I'll try to write the second RFC soon (hopefully I'll have time) and we can do the maintainer

Re: [PHP-DEV] [RFC] get_class() disallow null parameter

Works for me  On 15 Aug 2016 10:17 p.m., "Dan Ackroyd" wrote: > On 14 August 2016 at 19:01, Marco Pivetta wrote: > > Hi Dan, > > > > This is a SemVer violation, but it doesn't seem like PHP follows SemVer > > closely, so I'm a bit confused about

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

On 8/14/16 4:13 PM, Yasuo Ohgaki wrote: "Now assume a 128 bit session identifier that provides 64 bits of entropy. What exactly does this mean? If it means that an attacker knows how to eliminate 2^128 - 2^64 impossible SID values from a search then that SID generation is insecure,

Re: [PHP-DEV] [RFC] get_class() disallow null parameter

On 14 August 2016 at 19:01, Marco Pivetta wrote: > Hi Dan, > > This is a SemVer violation, but it doesn't seem like PHP follows SemVer > closely, so I'm a bit confused about whether this can target 7.x. It was broken in a minor release, it can be fixed in a minor release imo.

Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

Hi! >> utf8_decode()/utf8_encode are, at best, extremely misleading names. >> Many uses of them in my experience go something like this: "I have an >> encoding problem, it's something to do with UTF-8, I'll try >> utf8_encode; hm, that didn't work, I'll try utf8_decode instead". I still think if

Re: [PHP-DEV] Namespaces internal refactoring

On 8/15/2016 12:11 AM, Stanislav Malyshev wrote: > Hi! > >> - PHP 7 has private classes through anonymous/inner classes. > > It's not exactly the same, and I suspect the same is true for Ruby. It's > true that anonymous classes can not be instantiated by other code. But > that is not what we

[PHP-DEV] Re: [RFC] orphan extensions cleanup

Hi! On 15.08.2016 at 18:46, Stanislav Malyshev wrote: >> Generally, I'm all for moving unmaintained extensions to PECL. >> However, I wonder on what information the concrete selection of >> unmaintained extensions in the RFC is based. If it is >> php-src/EXTENSIONS, the RFC is moot, in my

Re: [PHP-DEV] rethinking security issues in bugs db

Hi Stas 2016-08-15 19:12 GMT+02:00 Stanislav Malyshev : > Hi! > > I think the way security/private issues are implemented now in bugs DB > is wrong. It allows only access to a handful of people, and many package > maintainers and people that know the code in question are

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-15 19:09 GMT+02:00 Lester Caine : > We will do what WE have to to maintain it, but none of us are up to > speed with current PHP 'style' of coding so we also need help which is > how we managed to get the PHP7 version updated. I do not understand that statement, the

Re: [PHP-DEV] rethinking security issues in bugs db

On 15.08.2016 at 19:28, Niklas Keller wrote: > It's anyway bad to have per bug passwords instead of simple user accounts > where you can see all your reported bugs without a PHP.net account. Well, the advanced search allows to filter by author email, e.g.

[PHP-DEV] Re: [RFC][VOTE] Add session_create_id() function

On 8/13/16 9:02 PM, Yasuo Ohgaki wrote: Hi Tom, On Sun, Aug 14, 2016 at 12:35 AM, Tom Worster wrote: Rather than argue the details of randomness, I have more basic comments. 1. If an app needs to access session values, it can and should do this without indirection through

Re: [PHP-DEV] rethinking security issues in bugs db

2016-08-15 19:12 GMT+02:00 Stanislav Malyshev : > Hi! > > I think the way security/private issues are implemented now in bugs DB > is wrong. It allows only access to a handful of people, and many package > maintainers and people that know the code in question are excluded.

[PHP-DEV] rethinking security issues in bugs db

Hi! I think the way security/private issues are implemented now in bugs DB is wrong. It allows only access to a handful of people, and many package maintainers and people that know the code in question are excluded. This makes promptly handling bugs very hard. I propose one of: 1. Adding a lot

Re: [PHP-DEV] [RFC] orphan extensions cleanup

On 15/08/16 18:02, Kalle Sommer Nielsen wrote: > 2016-08-15 18:05 GMT+02:00 Lester Caine : >> > Don't go there again! > If there is no active maintainer, it just creates a burden on us core > developers that have to maintain it to the best of our abilities if > any, but there

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-15 18:05 GMT+02:00 Lester Caine : > Don't go there again! If there is no active maintainer, it just creates a burden on us core developers that have to maintain it to the best of our abilities if any, but there have not been anyone to take over the charge of this

Re: [PHP-DEV] [RFC] orphan extensions cleanup

Hi! > gettext > WordPress can optionally use gettext for some of their po/mo files, > I'm not entirely sure how this is today[1], but it might be worth > taking into consideration if there are other users. Maybe then somebody from Wordpress would be interested in taking over maintainership? --

Re: [PHP-DEV] [RFC] orphan extensions cleanup

Hi! >> enchant: >> I thought Pierre maintained enchant? Despite it haven't had much real >> activity for years > > Well there are not much changes in the api. > > And it works. So -1 here. Wait, -1 for what? Having a maintainer? How that makes sense? OK, there's no changes in API, but tomorrow

[PHP-DEV] Re: [RFC] orphan extensions cleanup

Hi! > Generally, I'm all for moving unmaintained extensions to PECL. > However, I wonder on what information the concrete selection of > unmaintained extensions in the RFC is based. If it is > php-src/EXTENSIONS, the RFC is moot, in my opinion, as this file is > grossly out-dated. It seems that

Re: [PHP-DEV] [RFC] orphan extensions cleanup

On Aug 15, 2016 3:17 PM, "Kalle Sommer Nielsen" wrote: > > Hi Stas > > 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev : > > Hi! > > > > I'd like to propose an RFC to deal with extensions that currently have > > no maintainer: > > > >

Re: [PHP-DEV] [RFC] orphan extensions cleanup

On 15/08/16 11:41, Nikita Popov wrote: > I think the interbase extension is missing from this list, I don't think it > has an active maintainer. Don't go there again! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic

[PHP-DEV] Re: [RFC: PATCH v1] Implement mt_srand_array

Hi Lauri, Do you have a PR against php-src on github? It's easier to read and comment. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Simple variable handling.

On 15/08/16 11:25, Tony Marston wrote: > The Data Dictionary is one that I wrote, and is available in my open > source Radicore framework. > > I don't use PDO as it was not created until years AFTER I had built my > own solution. Besides, PDO does not do data validation. > > I have no intention

[PHP-DEV] Re: [RFC] orphan extensions cleanup

On 15.08.2016 at 07:53, Stanislav Malyshev wrote: > I'd like to propose an RFC to deal with extensions that currently have > no maintainer: > > https://wiki.php.net/rfc/umaintained_extensions > > The main goal of the RFC is to initiate the process that by the time of > 7.1 release will result

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

On 15.08.2016 at 13:00, Tony Marston wrote: > "Dan Ackroyd" wrote in message > news:ca+kxmuriobqpmtekqnyv8rx0gkclryixi--y5tcyukdqpt7...@mail.gmail.com... > >> "Input data validation should accept only valid and possible inputs. >> If not, reject it and terminate program." > > I DISagree 100%.

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-15 12:41 GMT+02:00 Nikita Popov : > Is the a list of extension maintainers somewhere? Although not updated that often, in fact I think it haven't been truly updated for years, there is php-src/EXTENSIONS. Although this information could probably be better kept in the

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

"Dan Ackroyd" wrote in message news:ca+kxmuriobqpmtekqnyv8rx0gkclryixi--y5tcyukdqpt7...@mail.gmail.com... Hi Yasuo, On 15 August 2016 at 01:53, Yasuo Ohgaki wrote: One more usual request. Please describe reason(s) why you object proposal. I'm not entirely sure why

Re: [PHP-DEV] Simple variable handling.

"Marco Pivetta" wrote in message news:CADyq6s+LjfL5g2mLNz=XSk7BWT=p3vftgsicgjgck-tz0ce...@mail.gmail.com... Hey Tony, On Sun, Aug 14, 2016 at 10:50 AM, Tony Marston wrote: "Marco Pivetta" wrote in message news:CADyq6sKZRBvYFtqyKYVYM4iU

Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

On 15/08/2016 06:26, Stanislav Malyshev wrote: Hi! Hi all, utf8_decode() and utf8_encode() are not needed and causing problems than solving. Why you think they are not needed? I'm guessing this came about from their mention on another thread. To quote myself: utf8_decode()/utf8_encode

Re: [PHP-DEV] [RFC] orphan extensions cleanup

On Mon, Aug 15, 2016 at 7:53 AM, Stanislav Malyshev wrote: > Hi! > > I'd like to propose an RFC to deal with extensions that currently have > no maintainer: > > https://wiki.php.net/rfc/umaintained_extensions > > The main goal of the RFC is to initiate the process that by

Re: [PHP-DEV] Re: [RFC] get_class() disallow null parameter

On 15.08.2016 at 02:09, Stanislav Malyshev wrote: >> Prohibiting `get_class(NULL)` is certainly a good idea, but I have some >> concerns regarding BC. While `__CLASS__` has been introduced with PHP >> 4.3.0, it had the glitch to return the lower-cased class name before PHP >> 5.0.0. So there

Re: [PHP-DEV] Simple variable handling.

"Lester Caine" wrote in message news:4b381281-204d-5e57-0bba-127ab8d2e...@lsces.co.uk... On 15/08/16 10:11, Tony Marston wrote: The origins of $fieldarray should be obvious. The $fieldspecs array is constructed from data which is originally extracted from the database schema, imported into my

Re: [PHP-DEV] Simple variable handling.

On 15/08/16 10:11, Tony Marston wrote: > The origins of $fieldarray should be obvious. The $fieldspecs array is > constructed from data which is originally extracted from the database > schema, imported into my Data Dictionary, then exported into a PHP > script which is then included when the

Re: [PHP-DEV] Simple variable handling.

"Lester Caine" wrote in message news:fe222876-6875-3f07-e25b-aea2cbbed...@lsces.co.uk... On 14/08/16 09:50, Tony Marston wrote: If you are still writing code to perform primary validation on each field then your coding style is way behind the times. At some point you need to know the rules

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-15 10:23 GMT+02:00 Sebastian Bergmann : > I consider this part of the core. It's (mostly) auto-generated anyway, right? The token list is generated from the core using ext/tokenizer/tokenizer_data_gen.sh, rest is just to expose the two functions, so yes pretty much

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

On 15/08/16 06:17, Stanislav Malyshev wrote: >> There is misunderstanding on this. >> > As I wrote explicitly in the RFC, input validation and user input >> > mistakes must be handled differently. >> > >> > "The input validation (or think it as assertion or requirement) error" >> > that this RFC

Re: [PHP-DEV] [RFC] orphan extensions cleanup

Am 15.08.2016 um 10:17 schrieb Kalle Sommer Nielsen: > tokenizer > Like you mentioned, I think this should be kept in the core and > possibly maintained as a part of the parser. I do write some > development tools every now and then and make use of this amazing > extension and will only want it to

Re: [PHP-DEV] [RFC] orphan extensions cleanup

Hi Stas 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev : > Hi! > > I'd like to propose an RFC to deal with extensions that currently have > no maintainer: > > https://wiki.php.net/rfc/umaintained_extensions enchant: I thought Pierre maintained enchant? Despite it haven't had

Re: [PHP-DEV] Namespaces internal refactoring

On 15/08/16 01:42, guilhermebla...@gmail.com wrote: >>> Annotation parser needs to understand what was "use"d, so it can >>> > > properly refer to FQCN. That way, we need to somehow discover something >> > >> > I see what you mean. This seems to be a problem because you are trying >> > to do