Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > All it is, really, is a registry for functions, and syntactic sugar for > calling those functions - it's unnecessary, it's more global state you have > to manage and it's the kind of superficial convenience that will end up > breeding more complexity. > Registry of functions - is exactly how

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

I've read your RFC, and I think this a strange feature. All it is, really, is a registry for functions, and syntactic sugar for calling those functions - it's unnecessary, it's more global state you have to manage, and it's the kind of superficial convenience that will end up breeding more

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> Hacking non FQN resolutions to inject another > escaper implementation as in "" was a > creative idea but it seems inconsistent with the preferable "PHP way" to > handle these edge cases. Just imagine use cases like: That way people can use the escaping operator in all kinds of templates

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > Multiple arguments would make the syntax even cleaner: > > I thought about it. Multiple arguments do not allow runtime modification (and make the parser more complex). Something like this: name == 'url') $context[] = 'url'; $context[] = 'html'; ?> ​

Re: [PHP-DEV] Idea: Function autoloading using dummy namespaces

On Sun, Jul 17, 2016 at 8:21 PM, Rowan Collins wrote: > Hi All, > > In the discussion of escaping mechanisms, it's once again come up that > functions lack autoloading, and thus are hard to work with in larger code > bases. > > Previous solutions to this, most notably

Re: [PHP-DEV] Idea: Function autoloading using dummy namespaces

> I don't think this is realistic. I'll come back to this one in a moment. > As such: > > Option B: foo() in namespace Bar will > a) Check if Bar\foo() exists > b) Otherwise check if foo() exists > c) Otherwise try to load 'Bar\foo' > d) Otherwise try to load 'foo' > e) If all fails, throw. > >

[PHP-DEV] Re: Dropping SSL2 in 7.1

On Wed, Jul 13, 2016 at 8:11 PM, Jakub Zelenka wrote: > Hi, > > It's been already proposed by Remi using PR [1] so sending it here as > well. I would like to proceed and drop SSL2 support from PHP. Effectively > it means dropping ssl2 stream as it's not already negotiated by

Re: [PHP-DEV] Re: Bumping minimal OpenSSL version to 1.0.1 in master for PHP 7.1

On Fri, Jul 15, 2016 at 10:18 PM, Niklas Keller wrote: > 2016-07-15 18:30 GMT+02:00 Jakub Zelenka : > >> Hi, >> >> On Fri, Jul 15, 2016 at 9:48 AM, Pierre Joye >> wrote: >> >> > hi, >> > >> > On Fri, Jul 15, 2016 at 5:07 AM, Stanislav

[PHP-DEV] orphaned extensions in 7.1?

Hi! I wonder if we shouldn't move orphaned extensions out of the core and in PECL in 7.1? If nobody maintains the code, should it really be part of the core? Right now we have two orphaned extensions - wddx and xmlrpc, I suspect both are not too widely used now. They also had some issues, and

Re: [PHP-DEV] Idea: Function autoloading using dummy namespaces

On Mon, Jul 18, 2016 at 4:53 AM, Nikita Popov wrote: > > Option B: foo() in namespace Bar will > a) Check if Bar\foo() exists > b) Otherwise check if foo() exists > c) Otherwise try to load 'Bar\foo' > d) Otherwise try to load 'foo' > e) If all fails, throw. > > This avoids

Re: [PHP-DEV] orphaned extensions in 7.1?

The only negative I see for this is that it reinforces PECL as being Siberia. Having said that, it's better than deleting them, and they shouldn't be in core. - Davey On Sun, Jul 17, 2016 at 5:03 PM, Stanislav Malyshev wrote: > Hi! > > I wonder if we shouldn't move

Re: [PHP-DEV] orphaned extensions in 7.1?

Hi! > The only negative I see for this is that it reinforces PECL as being > Siberia. Having said that, it's better than deleting them, and they > shouldn't be in core. Right. We want to keep them somewhere in case somebody wants to pick them up and use them or maintain them. -- Stas Malyshev

Re: [PHP-DEV] Idea: Function autoloading using dummy namespaces

Hi! > How about an alternative approach where a function inside a namespace > can be autoloaded using the existing callback, by using a reserved > namespace segment? So to autoload function "foo\bar()", the engine would > construct a string like "__function\foo\bar" or "foo\__function\bar", > and

Re: [PHP-DEV] Idea: Function autoloading using dummy namespaces

On Mon, Jul 18, 2016 at 1:28 AM, Levi Morrison wrote: > > I don't think this is realistic. > > I'll come back to this one in a moment. > > > As such: > > > > Option B: foo() in namespace Bar will > > a) Check if Bar\foo() exists > > b) Otherwise check if foo() exists > > c)

Re: [PHP-DEV] Idea: Function autoloading using dummy namespaces

>> I think a better option is to try to solve this in 8 by unifying how >> functions and classes (and interfaces and traits) work in namespaces. >> Ideally the lookup behavior should be the same and all that differs >> are the symbol tables being looked in. > > > Are you suggesting that we require

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

On 2016-07-17 06:49, Marcio Almada wrote: 2 . Is there any rationale why we're using strings separated by '|' to pass context instead of an array? Ex.: Multiple arguments would make the syntax even cleaner: -- Lauri Kenttä -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

2016-07-17 12:35 GMT+02:00 Michael Vostrikov : > > > > Multiple arguments would make the syntax even cleaner: > > > > > > I thought about it. Multiple arguments do not allow runtime modification > (and make the parser more complex). > Something like this: >

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > Context should be defined where the variable is printed. Otherwise you > move the variable from HTML text to an attribute or add it somewhere else > and the context doesn't match anymore. > Well, maybe, but HTML is external context and it can be combined with other contexts depending on task.

[PHP-DEV] Idea: Function autoloading using dummy namespaces

Hi All, In the discussion of escaping mechanisms, it's once again come up that functions lack autoloading, and thus are hard to work with in larger code bases. Previous solutions to this, most notably Anthony Ferrara's very thorough RFC [1], have looked at adding new modes for the existing

Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements

On Mon, Jul 11, 2016 at 10:30 AM, Aaron Piotrowski wrote: > Hi Levi, > > On Jul 9, 2016, at 10:12 AM, Levi Morrison wrote: > > On Sat, Jul 9, 2016 at 8:16 AM, Aaron Piotrowski wrote: > > > Additionally, I propose adding a getName() method to

Re: [PHP-DEV] orphaned extensions in 7.1?

Hello internals, I work for Moodle (https://en.wikipedia.org/wiki/Moodle) We recently implemented an XML-RPC server using the XML-RPC extension. I actually found a bug in it and am working on a patch in my spare time. If there is a maintaner needed for the extension, I would be happy to