Hi all and RM,
On Sat, Jul 2, 2016 at 4:35 PM, Yasuo Ohgaki wrote:
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> Thi
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
volunteer
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 the autoloading overhe
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
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
s
>> 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
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 orphaned extensions out of th
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 wit
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) Otherwise try to load
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 ReflectionType that
> returns only the name of the typ
> 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.
>
> T
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 default.
>
> It's bee
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 Malyshev <
>> smalys...@gmail.com>
>> > wrote:
>> > > Hi!
>>
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 Anthony Ferrara's very thoro
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 a
>
> 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 e
> 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 w
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 complex
>
> 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.
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:
> $context = [];
> if ($field->n
>
> 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';
?>
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 unsubsc
22 matches
Mail list logo
