Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

[Paul Dragoonis]

On Fri, 23 Aug 2024, 11:02 Stephen Reay,  wrote:

>
>
> > On 23 Aug 2024, at 15:29, Rowan Tommins [IMSoP] 
> wrote:
> >
> > having global as the default mode (even if we provide an option for
> local) is much less disruptive to existing code.
>
> Hi Rowan,
>
> I don't disagree with this summary of the current state, but I think this
> misses an important factor: namespaced functions are currently nowhere near
> as popular as namespaced classes, and a significant part of that is almost
> certainly because we don't have function autoloading, nor any kind of
> visibility controls for functions (eg package private).
>
> Making relative function names do the opposite of relative class names
> sounds like a great way to permanently kill any prospects of encouraging
> developers to use regular namespaced functions in place of static classes
> as "bag of functions", which is what we keep hearing we should use - most
> notably on a recent RFC to embody the concept of a static class.
>
> So we're told "no don't use classes for static functions like that, use
> proper functions".
>
> We already can't autoload them which makes them less appealing, and less
> practical.
>
> In a world where global functions take precedence over local ones because
> some people don't like writing a single \ character, autoloading would be a
> moot point because if you preference global functions you're implicitly
> telling developers they shouldn't write namespaced functions, by making
> them harder and less intuitive to use.
>
>
> Cheers
>
> Stephen



I've taken the time to carefully read Ilija's proposal and all followup
messages.

This is a great proposal, Ilija, it will immediately benefit 95%+ userbase.

It looks to me that the pro's outweigh the con's, as well as Ilija having
done good research here already.

As for next steps, I'm suggesting that Ilija reach out to the core team at
Symfony, Zend, Laravel as well as WordPress, Magento, Drupal teams .. for
their consideration and input, and bring it back here/RFC.

The latter group of project's codebases can be quite "quirky", and quite
creative, in how they use PHP compared to a traditional "framework".

We need to understand how this could negatively impact how their systems
are put together, and we definitely want to, upfront, identify anything we
wouldn't normally think of, that they can spot, since they know their own
codebases better than we do.

We already have the composer analysis, so after we have these
framework/project analysis then we can make a strongly informed decision on
the impact, positively or negatively, this change will make.

Many thanks,
Paul

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Paul Dragoonis]

On Fri, Jun 21, 2024 at 10:12 AM Paul Dragoonis  wrote:

>
>
> On Thu, Jun 20, 2024 at 11:54 PM Rowan Tommins [IMSoP] <
> imsop@rwec.co.uk> wrote:
>
>> On 19/06/2024 16:34, Larry Garfield wrote:
>>
>> Also, as someone who does put every file into strict mode as a matter of
>>  course, and appreciates the many languages that do not even have a
>> concept of non-strict mode (like Go or Rust), I really don't appreciate
>> the backhanded comments in this thread about people who, you know, care
>> about type safety.  (Something that weak mode, when it was introduced in
>>  PHP 7, only marginally provided if at all.)  Strict mode prevents bugs,
>>  full stop, and we should not fault anyone for applying that bug-stopper
>>  tool liberally.
>>
>>
>>
> Hey Rowan,
>

I meant Hey Robert, but half replying to Rowan's suggestions too.


>
> What Gina, Larry and Sebastian said.
>
> My $0.02 is
>
> 1. typing "declare(strict_types=1);" is already cumbersome enough, we
> don't need to be adding more words and complexity to it
>
> 2. adding the word "coerce" or "coercion" to a thing is really not good
> from a DX (developer experience) perspective. It will not add clarity it
> will add *confusion*... "What is this coersion thing I've never heard of"
>
> 3. remember who the target audience is.. Rust and Golang are not
> beginner-friendly or entry-level languages, so the fact you're even using
> Rust means you know what you're doing and likely know what coersion is
>
> 3.1 PHP's strength is that it's beginner friendly and by that I mean just
> remember a significant portion of our userbase are Wordpress developers
> (and Drupal / Magento alike) .. and many WP devs won't have even heard of
> Dependency Injection before nevermind the complexities of type coersion, so
> we need to keep things *simple as possible* at all times
>
> 4. I think the solution you're looking here for is better *education* to
> the end-users, on what the implications of X or Y are .. rather than
> changing the language itself .. so the merits of your proposal are good, in
> that it helps the end-user understand the system better .. it's just the
> solution you're proposing here just isn't it (so far).
>
>
>
> Used correctly, it absolutely does. Used incorrectly, it can actually end
>> up *hiding* errors.
>>
>> I've seen lots of cases where code like this:
>>
>> some_function_expecting_int($_GET['foo']);
>>
>> Gets changed to this:
>>
>> declare(strict_types=1);
>> some_function_expecting_int( (int)$_GET['foo'] );
>>
>> Even in PHP 7.0, the first version is actually *stricter* than the
>> second, because explicit casts never fail, but parameter coercion (mode 0)
>> always failed for strings like "hello"; as of 8.0, it also fails for
>> strings like "123foo" and "".
>>
>> And this is exactly the kind of code that coercive type hints were
>> intended for - HTTP is a text-based protocol, so most PHP applications are
>> dealing with string input and output *all the time*.
>>
>> One of the things the language badly needs, and I have been trying to
>> come up with a proposal for, is strict type casts, so that this code can
>> actually be written safely but still concisely.
>>
>>
>> Regards,
>>
>> --
>> Rowan Tommins
>> [IMSoP]
>>
>>

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Paul Dragoonis]

On Thu, Jun 20, 2024 at 11:54 PM Rowan Tommins [IMSoP] 
wrote:

> On 19/06/2024 16:34, Larry Garfield wrote:
>
> Also, as someone who does put every file into strict mode as a matter of
>  course, and appreciates the many languages that do not even have a
> concept of non-strict mode (like Go or Rust), I really don't appreciate
> the backhanded comments in this thread about people who, you know, care
> about type safety.  (Something that weak mode, when it was introduced in
>  PHP 7, only marginally provided if at all.)  Strict mode prevents bugs,
>  full stop, and we should not fault anyone for applying that bug-stopper
>  tool liberally.
>
>
>
Hey Rowan,

What Gina, Larry and Sebastian said.

My $0.02 is

1. typing "declare(strict_types=1);" is already cumbersome enough, we don't
need to be adding more words and complexity to it

2. adding the word "coerce" or "coercion" to a thing is really not good
from a DX (developer experience) perspective. It will not add clarity it
will add *confusion*... "What is this coersion thing I've never heard of"

3. remember who the target audience is.. Rust and Golang are not
beginner-friendly or entry-level languages, so the fact you're even using
Rust means you know what you're doing and likely know what coersion is

3.1 PHP's strength is that it's beginner friendly and by that I mean just
remember a significant portion of our userbase are Wordpress developers
(and Drupal / Magento alike) .. and many WP devs won't have even heard of
Dependency Injection before nevermind the complexities of type coersion, so
we need to keep things *simple as possible* at all times

4. I think the solution you're looking here for is better *education* to
the end-users, on what the implications of X or Y are .. rather than
changing the language itself .. so the merits of your proposal are good, in
that it helps the end-user understand the system better .. it's just the
solution you're proposing here just isn't it (so far).



Used correctly, it absolutely does. Used incorrectly, it can actually end
> up *hiding* errors.
>
> I've seen lots of cases where code like this:
>
> some_function_expecting_int($_GET['foo']);
>
> Gets changed to this:
>
> declare(strict_types=1);
> some_function_expecting_int( (int)$_GET['foo'] );
>
> Even in PHP 7.0, the first version is actually *stricter* than the second,
> because explicit casts never fail, but parameter coercion (mode 0) always
> failed for strings like "hello"; as of 8.0, it also fails for strings like
> "123foo" and "".
>
> And this is exactly the kind of code that coercive type hints were
> intended for - HTTP is a text-based protocol, so most PHP applications are
> dealing with string input and output *all the time*.
>
> One of the things the language badly needs, and I have been trying to come
> up with a proposal for, is strict type casts, so that this code can
> actually be written safely but still concisely.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
>

Re: [PHP-DEV] New "PECL"

[Paul Dragoonis]

On Tue, Dec 5, 2023 at 3:25 PM Paul Dragoonis  wrote:

>
>
> On Tue, Dec 5, 2023 at 3:21 PM Pierre Joye  wrote:
>
>> On Tue, Dec 5, 2023, 10:13 PM Pierre Joye  wrote:
>>
>> >
>> >
>> > You may mention https://github.com/FriendsOfPHP/pickle
>> >
>> > which supports pecl.php.net pear format,  composer like support, and
>> > conversion to composer format.
>> >
>> > I did a website as well as a test bed and we had a long with the
>> composer
>> > team what would be the best way to integrate it. That's something that
>> > became possible with composer 2.x, which now widely used. Similarly we
>> > discussed the idea to create a packagist dedicated to extensions.
>> >
>> > That would be, imo, the best option to date.
>> >
>> >
>> > The current code may need some updates for php8 but nothing difficult or
>> > requiring big changes.
>> >
>>
>> there was also a draft rfc while we were thinking to propose to bundle it.
>> But we then decided to follow the composer's packagist philosophy instead.
>>
>> https://wiki.php.net/rfc/pickle
>>
>>
> Hi Derick,
>
> Thanks for creating the google doc for us, it's really easy to contribute
> now, and I think I'll use this same approach for php.net/docs
> modernization approach.
>
> I came here to write about Pierre's Pickle project, but he replied whilst
> I was mid-writing this email :-)
>
> I'll add comments onto the Google Doc.
>
> Many thanks,
> Paul
>

Hi Derick,

I've added my comments, for now, in the first part of the document.

As for the latter points in the document, such as json structures and so
on, I think it might make sense to complete the Pickle evaluation, as a
first phase thing, because the way Pickle is designed may influence how
packages are structured.

I'm very enthusiastic to hear how this topic evolves :-)

Have a great day <3

Many thanks,
Paul


>
>
>> >
>>
>

Re: [PHP-DEV] New "PECL"

[Paul Dragoonis]

On Tue, Dec 5, 2023 at 3:21 PM Pierre Joye  wrote:

> On Tue, Dec 5, 2023, 10:13 PM Pierre Joye  wrote:
>
> >
> >
> > You may mention https://github.com/FriendsOfPHP/pickle
> >
> > which supports pecl.php.net pear format,  composer like support, and
> > conversion to composer format.
> >
> > I did a website as well as a test bed and we had a long with the composer
> > team what would be the best way to integrate it. That's something that
> > became possible with composer 2.x, which now widely used. Similarly we
> > discussed the idea to create a packagist dedicated to extensions.
> >
> > That would be, imo, the best option to date.
> >
> >
> > The current code may need some updates for php8 but nothing difficult or
> > requiring big changes.
> >
>
> there was also a draft rfc while we were thinking to propose to bundle it.
> But we then decided to follow the composer's packagist philosophy instead.
>
> https://wiki.php.net/rfc/pickle
>
>
Hi Derick,

Thanks for creating the google doc for us, it's really easy to contribute
now, and I think I'll use this same approach for php.net/docs modernization
approach.

I came here to write about Pierre's Pickle project, but he replied whilst I
was mid-writing this email :-)

I'll add comments onto the Google Doc.

Many thanks,
Paul



> >
>

Re: [PHP-DEV] PHP 8.3.0 Released!

[Paul Dragoonis]

On Thu, Nov 23, 2023 at 4:57 PM Jakub Zelenka  wrote:

> The PHP development team announces the immediate availability of PHP 8.3.0.
> This release marks the latest major release of the PHP language.
>
> PHP 8.3 comes with numerous improvements and new features such as:
> - Typed Class Constants
> - Fetch class constant dynamically syntax
> - Readonly Amendments
> - Override Attribute
> - New Randomizer method Random\Randomizer::getBytesFromString
> - New function json_validate
> - And much much more...
>
> For source downloads of PHP 8.3.0 please visit our downloads page
> (https://www.php.net/downloads.php), Windows source and binaries can be
> found on https://windows.php.net/download/.
> The list of changes is recorded in the ChangeLog
> (https://www.php.net/ChangeLog-8.php#8.3.0).
> The migration guide (http://php.net/manual/en/migration83.php) is
> available
> in the PHP Manual.
> Please consult it for the detailed list of new features and backward
> incompatible changes.
>
> Many thanks to all the contributors and supporters!
>
> Release Manifest here and below:
> https://gist.github.com/bukka/9b83d9718de090953eec989be16ba91a
>
> Jakub Zelenka, Eric Mann, & Pierrick Charron
>

What an achievement!

Just giving my personal thanks to Jakub, Eric, & Pierrick, and obviously to
all contributors, you all rock! :-)

Looking forward to trying it out

Many thanks,
Paul



>
> php-8.3.0.tar.bz2
> SHA256 hash:
> de67d0833d42b196e5a66fa1a332f45e296cbe8e9472e9256b2a071c34dc5ed6
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZVzCAgAKCRAcB3ncXAqd
> 5JBFAQCaYK3jZ8YtgaOUpIRTYsAEVf4wgHshahMsxyOOL9GP9AEAlz/sd2HK/Wod
> J9AsSbX68jX98PK0RG/WE+gA2L/DXQs=
> =Y0F0
> -END PGP SIGNATURE-
>
>
> php-8.3.0.tar.gz
> SHA256 hash:
> 557ae14650f1d1984d3213e3fcd8d93a5f11418b3f8026d3a2d5022251163951
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZVzCAwAKCRAcB3ncXAqd
> 5NDPAQDieVJDb9nL/HnB/mTLfzbcwIBiIVlQpGAp9V3WrYS6ZAD/cvQ5U4Uljaq2
> 2fv4hdBTjcaxlTjjsq+GK8GGz2C67gs=
> =n0At
> -END PGP SIGNATURE-
>
>
> php-8.3.0.tar.xz
> SHA256 hash:
> 1db84fec57125aa93638b51bb2b15103e12ac196e2f960f0d124275b2687ea54
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZVzCAwAKCRAcB3ncXAqd
> 5KKuAQCtutsDX4GEimUkxyeBOlHtAa3sZohmSimjchPlz0G3dwD/bDvvI836HsGt
> rZ3OAWTPI6e0W+M0MbJwq6o54sxDqQg=
> =eSjV
> -END PGP SIGNATURE-
>

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Paul Dragoonis]

On Sun, 15 Oct 2023, 04:49 Saki Takamachi,  wrote:

> I came up with the idea of ​​using a signature like array_filter(), and
> when a callback is passed, "return the first/last element that matches the
> condition" and "return null if there is no match."
>
> The downside to this idea is the loss of simplicity. So I'll leave it up
> to you whether you want to go with this idea or not. I have no intention of
> forcing this.
>
> Best regards.
>

I'm in favor of these functions.

Right now I am doing:

$firstItem = current($array)
$secondItem = next($array)

Which is simple and works, but really it's just by design that the code
hasn't shifted the array pointer yet and I can cheat with current()

If the pointer was shifted then I'd have to do reset(), which isn't good.

array_first() for the win

Many thanks,
Paul




> Saki
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Discussion] A new JIT implementation based on IR Framework

[Paul Dragoonis]

On Thu, 5 Oct 2023, 17:44 Dmitry Stogov,  wrote:

> Hi Internals,
>
> I've published a presentation about the IR Framework design and
> implementation details.
> See
>
> https://www.researchgate.net/publication/374470404_IR_JIT_Framework_a_base_for_the_next_generation_JIT_for_PHP
> It explains many complex things in simple pictures.
>

Hi Dmitry,

Thanks for helping explain things in graphical format. I will for sure
study the material closely.

As for the point around keeping the old JIT around as a safety measure and
fallback.

I think this is an excellent idea and may give good peace of mind and
confidence for new adopters, that they can easily "switch back" to JIT 1.0
if any edge cases occur we didn't find yet in JIT 2.0, without waiting for
future PHP releases (patches) to come out.

It can be months before people get new patched PHP versions (think about
centos or Debian distributions, or Docker images of PHP)

Just like we've done with many things over the years, we first deprecated
something and keep it in the language and in future release we remove it
completely.

Many thanks,
Paul



> Thanks. Dmitry.
>
> On Thu, Sep 21, 2023 at 11:26 AM Dmitry Stogov 
> wrote:
>
> > Hi Internals,
> >
> > After all the Poll Request discussions (see
> > https://github.com/php/php-src/pull/12079), code-reviews and internal
> > discussions with core developers we decided to move this through the RFC
> > process.
> >
> > Thanks to all participants.
> >
> > The RFC is open for discussion: https://wiki.php.net/rfc/jit-ir
> >
> > Thanks. Dmitry.
> >
>

Re: [PHP-DEV] Remove warning when parsing datetime with + symbol?

[Paul Dragoonis]

On Mon, 28 Nov 2022, 16:32 Christoph M. Becker,  wrote:

> On 28.11.2022 at 16:50, Derick Rethans wrote:
>
> > On Thu, 24 Nov 2022, mickmackusa wrote:
> >
> >> Can anyone explain to me why it is desirable/beneficial for the DateTime
> >> class to store a warning that trailing characters were ignored while
> >> parsing a date/time string with the + symbol in createFromFormat()?
> >
> > I have no idea why I decided that was a good idea back all these years,
> > and I'm perfectly happy to remove that restriction from PHP 8.3
> > forwards — it's too late to do that in PHP 8.2 now, as it's being
> > released next week.
>
> That would appear to consitute a BC break.  From the docs:
>
> | If this format specifier is present, trailing data in the string will
> | not cause an error, but a warning instead
>
> This can be used to parse the date (without the +, parsing may fail),
> but still be able to return a message about ignored characters to the user.
>

We are allowed to break BC in minor version upgrades, Chris.

We can allow this is 8.3 I think, rather than waiting for 9.0

What do you think?



> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC: StreamWrapper Support for glob()

[Paul Dragoonis]

Hi Timmy,

Good suggestion.

This seems like a no brainer, and definitely good to add streams support
for glob filepaths. You're right, we currently have to work around this in
userland. Your code example workaround is super ugly :)

I'm intersted to know, from others, if there are deeper technical reasons
why this wouldn't be a good idea, because I'm not it

Unless my memory is wrong, Sara was heavily involved in the initial streams
API, and might be good to see what she thinks too, from an implementation
POV :)

Many thanks,
Paul






On Wed, 14 Sep 2022, 17:59 Timmy Almroth,  wrote:

> Hello everyone. I would like to announce that the RFC for "StreamWrapper
> Support for glob()" is now ready for Discussion.
>
> RFC
> https://wiki.php.net/rfc/glob_streamwrapper_support
>
> Feature Request and Discussions
> https://github.com/php/php-src/issues/9224
>
> Regards,
>
> Tim
>

Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling

[Paul Dragoonis]

On Thu, 8 Sep 2022, 17:18 Tim Düsterhus,  wrote:

> Hi
>
> On 9/7/22 23:44, Larry Garfield wrote:
> > Either I guess?  Honestly we should decide that in advance on the list.
> :-)  E_WARNING+Exception in 9 is what I'd probably favor, with "Exception
> now" as a second choice.
> >
>
> I'm a new-ish contributor here in internals, so I don't know how things
> were done in the past for similar situations/issues.
>

Welcome, Tim :-)

Do give it more thought regarding the callbacks what Nikolas said, sleep on
it.

Not saying it matters, but also double check how error handling MAY differ
when in a Class::_unserialize() context. Maybe it doesn't diff, I haven't
checked in a while, but food for thought.

In any case, good cleanup initiative.


> I'm not sure, though if it makes sense to already decide on something
> for PHP 9. If it's not baked into code shortly after the vote finishes,
> then people might forget that "there's something that still needs to be
> done". For a deprecation one can at least go through all the
> deprecations once PHP 9 opens, as a deprecation effectively is defined
> to be a removal in the next major. For a warning this is less obvious.
>
> Personally my first choice would be "Straight to Exception", so I might
> not be the best person to decide on that :-)
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Increase maximum size of an uploaded file to 50Mbyte

[Paul Dragoonis]

On Thu, 8 Sep 2022, 12:59 Christoph M. Becker,  wrote:

> On 08.09.2022 at 13:01, Andreas Heigl wrote:
>
> > On 08.09.22 12:35, Jakub Zelenka wrote:
> >
> >> On Wed, Sep 7, 2022 at 3:28 PM Christoph M. Becker 
> >> wrote:
> >>
> >>> On 07.09.2022 at 15:57, Misha wrote:
> >>>
>  We spend a lot of time to increase limits for uploads file in PHP.
>  Can we
>  increase it in php.ini?
> 
>  Current value is 2Mb. Its so small value, when photo image can take
> 8Mb
> >>> on
>  iPhone X.
>  We should increase it to 50Mb, because DevOps engineers do useless
> work
>  trying to change it.
> 
>  I have prepared PR for it https://github.com/php/php-src/pull/9315
> >>>
> >>> I'm not against increasing the sizes, but 50MB might be too much.
> >>>
> >>> Anyway, only changing the php.ini files doesn't make sense in my
> >>> opinion, since they're probably only used on Windows, and they should
> >>> reflect the actual default values[1].
> >>
> >>   It's true that those particular ini files are not directly used on
> >> Linux
> >> but distros often base their changes on them and the distro provided
> ones
> >> are actually used. So it means that main defaults in main.c are most
> >> likely
> >> not used. Although I agree they should be changed too so it is
> >> consistent.
> >
> > No matter which value we preset, it will most certainly not be adequate.
> >
> > So people *will* have to set it according to their needs. And if they
> > didn't so far, then they are happy with the current setting.
> >
> > Don't get me wrong: I'm not against changing that value.
> >
> > But is it really an issue that needs solving? It's a default value of a
> > configuration file. When I'm unhappy with the default, I change it to a
> > more suitable value. When I'm not able to do that... perhaps I should
> > leave my fingers not only from the config file...
>
> It might be worth to point out that we're using these defaults since PHP
> 4.0 (at least), so reconsidering sensible defaults might be appropriate.
>


I can sense we are all feeling like upping the value here.

If we take it slow and move from 2MB to 8MB that would ease into it, and
see how it goes in our next release ?

Do we RFC this? Who is volunteering to make it, if so? :-)



> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] Executing PHP SAPI/runtime from Golang/Rust

[Paul Dragoonis]

Hey,

So one thing that keeps me up at night (for a while now) is resisting the
urge not to venture down a rabbithole of writing code which is loading the
PHP runtime from Rust/Golang (up to MINIT)

And then at RINIT time, we load the right SAPI and pass across the SERVER
vars that's needed for it..

Here is a use case example. Golang concurrency model on the front, and it
can execute PHP CLI SAPI or HTTP SAPI on the back.

Moreover if you're looking at reasons people have previously or currently
moving away from PHP to other languages, due to limitations like pure async
or concurrency stuff .. then perhaps a new FRONTEND which can execute the
PHP runtime on the backend would be solving some things.

I appreciate this isnt a unique idea and maybe someone else from internals
has raised this before .. but I wanted to raise the topic to check the
viability of this if it is possible, and what blockers are in our way,
currently, if it's not even possible to share SAPI calls from another
language runtime.

Thanks for listening,
Paul Dragoonis.

I wrote this on my phone, so excuse typos and poor grammar :)

Re: [PHP-DEV] [RFC] Asymmetric visibility

[Paul Dragoonis]

On Fri, 5 Aug 2022, 20:53 Larry Garfield,  wrote:

> On Fri, Aug 5, 2022, at 2:27 PM, Michał Marcin Brzuchalski wrote:
> > Hi Larry,
> >
> > pt., 5 sie 2022, 19:09 użytkownik Larry Garfield  >
> > napisał:
> >
> >> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
> >> Asymmetric Visibility.
> >>
> >> https://wiki.php.net/rfc/asymmetric-visibility
> >>
> >> Details are in the RFC, but it's largely a copy of Swift's support for
> the
> >> same.
> >>
> >
> > Thanks for taking efforts on new RFC.
> >
> > Why not C# style property accessors? It feels more natural for me while
> > Swift solution IMHO looks weird/odd composed with PHP class definition
> > syntax. The arguments in favor from the RFC look forcibly (couldn't find
> > better word).
> >
> > Cheers,
> > Michał Marcin Brzuchalski
>
> There's a couple of reasons.  Ilija and I have spent quite a bit of time
> brainstorming through accessors, and there's still a lot to finalize there,
> and lots of bikeshed potential.  It's a non-simple problem space.  However,
> asymmetric visibility is a good stand-alone concept that can work without
> accessors, and has ample benefits of its own without accessors, and has far
> less bikeshed potential.  (There's minor debates that might be had over
> syntax, but the behavior is fairly "it is or it isn't".)
>
> So the primary reason is that this syntax allows us to have asymmetric
> visibility without having to think about accessors.  We can then, at some
> point in the future, have a different discussion about accessors and not
> have to worry about asymmetric visibility in the process.  The C# syntax by
> nature only works if they come together in the same RFC, or at least one
> RFC is built such that it locks in some decisions for the other RFC.
>
> As an example, one thing we've been discussing is if accessors should be
> inline with the property (a la Swift and C#) or annotated methods (as in
> Javascript and Python).  There's good arguments for both approaches, as
> well as good arguments against.  But those would have *extremely* different
> implications for how we represent asymmetric visibility.  So if we took the
> C# style for asymmetric visibility, that would realistically lock us into
> C# style accessors even before we've had the discussion about if we want
> that or not.  That's not good.
>
> (Please don't anyone try to debate which accessor approach to take here;
> the whole point is we want to introduce asymmetric visibility without
> having that debate yet.  We'll be able to have it in the future, I'm sure.
> There's other knock-on effects as well that I'm skipping for now as not
> relevant.)
>
> Keeping them separate also makes extending visibility rules in different
> directions (as noted in the Future Scope section) at some point in the
> future can also be done without bumping into accessors.  Whether or not
> those directions are useful is a topic for another time, but it again
> allows us to discuss those (like a "once" operation or a "package" scope,
> etc.) without worrying about the impact on accessors.
>
> Secondarily, the C# style means you have to look both before and after the
> property itself to know what its visibility rules are.  That's increased
> cognitive load.  This way, all of the various "flags" on a property remain
> in the same place, and presumably 99.999% of developers will put `public
> private(set)` right next to each other like that.  That makes the
> visibility readable all from one spot, and if all you're using is that and
> not accessors in the future, the impact on your existing reading skills is
> minimized.  This one is admittedly a bit more subjective, but readability
> and cognitive load are certainly considerations to, er, consider.
>



Feedback:

1. The idea is cool

2. when I opened the RFC and looked at the syntax, I wasnt able to
intuitively (self documenting code) figure out what and why was going on.

3. The syntax is heavily implicit as to what each keyword and syntax means,
so the general PHP developer would struggle or mis understand what is going
on.

4. MWOP's point of there being a lot of keywords and prefixes at class
property declaration is not really cluttered (lots going on), is accurate.
Perhaps splitting it into an explicit Attribute might yield a better DX?

Ilina and Larry, all in all I know this is a WIP and you're looking for
early feedback, so this is my feedback, to be considered.

Looking forward to reviewing future revisions of this.

Thanks for the effort and time you've put in so far <3



> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] What to do with qa.php.net?

[Paul Dragoonis]

It's useful to me, as I've always been able to merge PRs on the QA site,
because I've not been added to any php-web/php-src github repos since we
migrated over there.

However, if it's not too useful to the majority of people, then I'll still
vote to delete it/move stuff.

One less site for us all to maintain, the better IMO, :-)

On Thu, 7 Jul 2022, 17:54 Christoph M. Becker,  wrote:

> Hi all,
>
> I wonder what we should do with qa.php.net.  While that site probably
> was useful in the past (at least the possibility to merge Github PRs),
> it seems that it is mostly abandoned nowadays.  Besides some (partially)
> out-dated information, and apparently some TODO lists[1] which were
> never really addressed, it supports uploading and display of user
> submitted test results.  Especially the latter seems to be totally
> useless, or is there anybody having a look at these reports?  Ah, yes,
> there are also PFTT test results, although there have not been any
> updates for several years, and the PFTT2 project[2] has (fortunately)
> been abandoned.
>
> The only really relevant stuff on the Website is the listing of
> available QA releases, and the information on how to write PHPT test
> cases.  In my opinion both should be moved to somewhere else (the PHPT
> docs might go into the php-src repo, and the available QA releases could
> be listed on php.net).  Afterwards I suggest to tear down the Website.
>
> Thoughts?
>
> [1] 
> [2] 
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

[Paul Dragoonis]

I think the original goal of this RFC is to make PHP more expressive, and
less clunky (look at Jav).  This is a good goal and one much desired by the
community, but I think the approach here isn't the right fit or way to
achieve it

Writing code in strings is a DX nightmare, and static analysis challenge.

PHP is improving onto a more verbose, typed, but exprsssive language, and
this change would make that harder.

I'm also thinking if this could become a LCE/RCE vulnerability in a type of
eval() situation.  Not a huge point but just an observation.

Happy to re evaluate a new approach to solve the same problem that doesn't
involve coding inside strings.

On Fri, 18 Mar 2022, 14:09 Pierre,  wrote:

> Le 18/03/2022 à 15:02, Chase Peeler a écrit :
> > On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown 
> > wrote:
> >
> >> On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm 
> >> wrote:
> >>
> >>> On Thu, 17 Mar 2022, 23:27 Ilija Tovilo, 
> wrote:
> >>>
>  Hi everyone
> 
>  I'd like to start discussion on a new RFC for arbitrary string
>  interpolation.
>  https://wiki.php.net/rfc/arbitrary_string_interpolation
> 
>  Let me know what you think.
> >>> That is a cool idea.
> >>> But I am not a big fan of having code in strings.
> >>> Wouldn’t this open the door to all kinds of new attacks?
> >> Do you have an example of a new kind of attack this would allow?
> >> The proposal doesn't enable interpolation of strings coming from
> >> a database or user input - it only applies to string literals
> >> directly in PHP code.
> >>
> >> Personally I'm really looking forward to having this functionality.
> >> Just a couple days ago I wanted to call a function in an interpolated
> >> string, and it was really annoying to have to wrap the function in a
> >> closure in order to use it.
> >>
> >> If this RFC is accepted I'd be able to replace code like this:
> >>
> >>  $name = "Theodore Brown";
> >>  $strlen = fn(string $string): int => strlen($string);
> >>  echo "{$name} has a length of {$strlen($name)}.";
> >>
> >> with
> >>
> >>  $name = "Theodore Brown";
> >>  echo "{$name} has a length of {$:strlen($name)}.";
> >>
> >>
> > Out of curiosity, why not:
> > $name = "Theodore Brown";
> > echo "{$name} has a length of ".strlen($name).".";
> >
> > or even
> > $name = "Theodore Brown";
> > $len = strlen($name);
> > echo "{$name} has a length of {$len}.";
>
> I guess it's a matter of taste and convention.
>
> Sometime, it make sense and it's just easier to just use string
> interpolation (for example with multiline templates).
>
> Regards,
>
> --
>
> Pierre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Paul Dragoonis]

On Wed, Mar 2, 2022 at 11:11 PM Paul Crovella 
wrote:

> On Wed, Mar 2, 2022 at 1:08 PM Stanislav Malyshev 
> wrote:
> >
> > That said, if somebody were to design a logo version with Ukraine flag
> >
>
> In case anyone has use for it: https://svgshare.com/i/epJ.svg
>
> Colors are #0057b7 and #ffd700, from
> https://en.wikipedia.org/wiki/Flag_of_Ukraine#Design, with a white
> stroke.
>

Opinions aside: PHP, like many other OSS projects, has substantial amounts
of people in Russia and non-Russia. Fact.

Let's keep an OSS project focusing on the technology that we're building
here, and take politics out of the equation here, entirely.

Please can we go to the correct platforms such as Twitter, FB, LinkedIn,
and others, for such conversations, discussions, moralities, and debates?

We all love the PHP project, and let's not get it dragged into the mess
going on in the outside world.

OSS for many is a safe haven to sink your work and focus into, stress
relief, an outlet, and a place free from outside world problems; let's try
to healthily keep it that way, shall we?

Nobody has to listen to me, but I really hope that you do.


>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] header() allows arbitrary status codes

[Paul Dragoonis]

On Thu, 23 Dec 2021, 00:06 David Gebler,  wrote:

> On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker 
> wrote:
>
> > Hi all,
> >
> > a while ago it has been reported[1] that our header() function actually
> > allows arbitrary status codes, which may even overflow.  Of course, that
> > makes no sense, since the status code is supposed to be a three digit
> > code.  So this ticket has been followed up by a pull request[2], and
> > Jakub suggested to further restrict the status code to be in range 100 -
> > 599.
> >
>
> Personally, I don't like restricting the status code to a number in the
> 100-599 range. As far as I know, RFC 7230 doesn't mandate anything beyond
> the requirement of 3 digits and while 7231 may only specify semantics for
> 1xx-5xx, that doesn't mean there isn't a legitimate use-case in custom or
> internal applications for status codes outside the usual semantics.
>
> The overflow part is a legit bug which can and should be fixed, but I'd at
> least question whether a user should be obliged to stick to conventional
> HTTP semantics via the header() function, or even a strictly conformant
> implementation of the standards defined 7320. Maybe this behaviour could be
> default but overridable via a new, fourth optional parameter or something,
> I don't know...but I can easily imagine someone having a legitimate context
> in which they want to send status codes outside the usual range
> representing custom semantics.
>


I think its safe to say we should restrict the overflow parts.

As for boundaries; I don't know who is or isn't using their own custom
status codes. It's unlikely, but entirely possible. As such, this is
considered a BC break.

If we apply restrictions to a minor release, then upgrading will be harder
for 8.2 if we include this in the next release.

You could say 98% of people are using standard ranges for status codes, but
we do have to always take into account the 2% on our decisions.

Thanks.




>
> >
> > Since this could break some pathological cases, I wanted to ask whether
> > anybody objects to this change for the master branch (i.e. PHP 8.2).
> >
> > [1] 
> > [2] 
> >
> > Christoph
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] [VOTE] Migrating to GitHub issues

[Paul Dragoonis]

Been wanting this since we first setup github.

I'm glad we're seriously reconsidering it again.

Nikita, If you want any help, with designing/writing scripts to perform the
data migration, then just DM me (Twitter?) and I will put in the
time/effort to make it happen.

Just let me know.

Thanks.


On Sat, 20 Nov 2021, 10:38 Nikita Popov,  wrote:

> Hi internals,
>
> I've opened voting on https://wiki.php.net/rfc/github_issues. The vote
> closes 2021-12-04.
>
> Please see https://externals.io/message/116302 for the RFC discussion, and
> https://externals.io/message/114300 for the pre-RFC discussion.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] Allow objects in define()

[Paul Dragoonis]

On Mon, Jun 14, 2021 at 7:47 PM Larry Garfield 
wrote:

> On Mon, Jun 14, 2021, at 9:35 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > With the introduction of enums, it's now possible for constants to hold
> > objects. However, this works only when using the `const X = Y` syntax,
> not
> > when using `define('X', Y)`, which still excludes objects.
> >
> > I've submitted https://github.com/php/php-src/pull/7149 to relax the
> > restriction. This means that define() would accept everything apart from
> > recursive arrays.
> >
> > An alternative here would be to allow define() to only accept enum
> objects
> > in particular, but not other objects. I would prefer not to do that, as
> > such a restriction would be rather arbitrary, now that the technical work
> > to support objects has been done. (PS: Please keep the difference between
> > mutability and interior mutability in mind.)
> >
> > Regards,
> > Nikita
>
> Sounds fine to me.  define() is runtime anyway so it should support
> runtime values.
>

Sounds sensible to me too. Good enhancement.


>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Changes to Git commit workflow

[Paul Dragoonis]

On Mon, 29 Mar 2021, 08:51 Paul Dragoonis,  wrote:

>
>
> On Mon, 29 Mar 2021, 02:30 Rasmus Lerdorf,  wrote:
>
>> On Sun, Mar 28, 2021 at 17:15 Sara Golemon  wrote:
>>
>> > On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella 
>> > wrote:
>> >
>> >> You might consider requiring commits be signed while you're at it.
>> >>
>> >>
>> > I suggested this as well, and even if we don't require it, we should
>> > STRONGLY encourage it.
>> >
>> > I've been signing my commits for several years now, it's not even that
>> > hard.
>> >
>> I think for php-src commits we can require it. For doc and other repos we
>> can make it optional for now until people are more comfortable with it.
>>
>
> Hey Rasmus,
>
> This is a good compromise.
>
> However, if you leave phpweb repo without signed commits then we're at
> risk from XSS or similar attacks still, and the surface area is really big
> because literally everyone is accessing the site.
>
> Many thanks,
> Paul
>

I also wanted to say; back when I was rebuilding our website a few years
ago, when you pushed to master it would automatically deploy this to the
live site.

If we are compromised and we still automatically roll out to production,
this would make it really easy for someone.

Can someone check how we currently do this, and maybe we should reconsider
auto production deploys, even if its temporary, to be on the safe side.


>
>
>
>> -Rasmus
>>
>

Re: [PHP-DEV] Changes to Git commit workflow

[Paul Dragoonis]

On Mon, 29 Mar 2021, 02:30 Rasmus Lerdorf,  wrote:

> On Sun, Mar 28, 2021 at 17:15 Sara Golemon  wrote:
>
> > On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella 
> > wrote:
> >
> >> You might consider requiring commits be signed while you're at it.
> >>
> >>
> > I suggested this as well, and even if we don't require it, we should
> > STRONGLY encourage it.
> >
> > I've been signing my commits for several years now, it's not even that
> > hard.
> >
> I think for php-src commits we can require it. For doc and other repos we
> can make it optional for now until people are more comfortable with it.
>

Hey Rasmus,

This is a good compromise.

However, if you leave phpweb repo without signed commits then we're at risk
from XSS or similar attacks still, and the surface area is really big
because literally everyone is accessing the site.

Many thanks,
Paul




> -Rasmus
>

Re: [PHP-DEV] [RFC] array_key_(first|last|index) functions proposal

[Paul Dragoonis]

Hi John,

Thanks for submitting the RFC. It just has one piece of something that I
feel needs a bit of refinement.

The balance of the $key and the $val is out of sync, with one param being
by-val and one by-ref.

You could simplify the function to remove the &$val altogether, since the
function name is about getting the key. Less is more here.

I know you pointed out examples of other unusual functions, but we must
live with those things historically for BC reasons. Given the opportunity
to get it right I'd like to propose removal of &$val so the function does
what its name says.

Thus it would look like this:
$val = $array[array_key_last($array)];

Many thanks,
Paul


On Fri, Jan 1, 2016 at 9:51 PM, John Bafford  wrote:

>
> > On Jan 1, 2016, at 16:38, Bishop Bettini  wrote:
> >
> > On Fri, Jan 1, 2016 at 3:44 PM, John Bafford  wrote:
> > Happy New Year, everyone!
> >
> > I’d like to present the first new PHP RFC for this year, a proposal to
> add functions to easily get the first, last, or an arbitrary key (and
> value) by index from an array, taking advantage of PHP’s property that
> arrays are ordered maps.
> >
> > Thanks for submitting this RFC!  I am +1, with one quibble: obtaining
> the value by reference seems non-sequitur to the function itself and PHP in
> general.  IOW, this seems more PHPesque to me:
> >
> > // get the next to last value
> > $key = array_key_index($arr, -2);
> > $val = $arr[$key];
> >
> > Sincerely,
> > bishop
>
> While relatively rare for PHP, these aren't the only functions that have
> an optional second return value by reference. (preg_match, preg_replace,
> str_replace, among others.)
>
> I agree that that’s a bit unusual in terms of PHP, but, if you actually
> need both the key and the value, this way you can do it in one call, rather
> than having to access the array and pull the value out of it separately.
> The C code already has a reference to the hashtable bucket, so returning
> the value if it’s needed is trivial.
>
> -John
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Bug #70805 (Segmentation faults whilst running Drupal 8 test suite)

[Paul Dragoonis]

Hey Bob,

Thanks, it was 2am and quite sleepy so wasn't considering the gen'd files.

Thanks for clarifying!

On Wed, Nov 4, 2015 at 2:26 AM, Bob Weinand  wrote:

> Hey,
>
> zend_vm_execute.h is an auto-generated file, via zend_vm_gen.php. In
> reality the patch only fixes the code in exactly one location
> (zend_vm_def.h) and then regenerated zend_vm_execute.h.
>
> Bob
>
> > Am 04.11.2015 um 03:10 schrieb Paul Dragoonis :
> >
> > Hey,
> >
> > Looking at the patch, the changes to zend_vm_def.h and zend_vm_execute.h
> > are duplicated in 10 locations. I'm wondering if we can consolidate this
> > into maintainable function/macro to handle this?
> >
> > On Wed, Nov 4, 2015 at 1:58 AM, Xinchen Hui  wrote:
> >
> >> Hey:
> >>
> >>
> >>
> >> On Wed, Nov 4, 2015 at 3:58 AM, Dmitry Stogov  wrote:
> >>
> >>> Hi,
> >>>
> >>> I think, I found the root problem of
> >> https://bugs.php.net/bug.php?id=70805
> >>>
> >>> unset($a) or unser($GLOBAL["a"]) triggered GC and destructors calls
> that
> >>> tried to release the same global variable $a  once again. As result
> it's
> >>> reference counter was decremented twice and this caused use-after-free,
> >>> double-free, etc.
> >>>
> >>> The proposed cumulative fix for all related problems:
> >>>
> >>> https://gist.github.com/dstogov/7aa9d24876e2b3fce8c5
> >>>
> >>> Xinchen, could you please review and verify this once again,
> >>> then add necessary tests and commit.
> >>>
> >> No problem, all issues we met are resovled , thanks :)
> >>
> >> tested and committed.
> >>
> >> and aslo thanks the fabian who provides us ssh access to a reproducible
> box
> >> (it's really hard to reproduce locally)
> >>
> >> thanks!
> >>
> >>>
> >>> Thanks. Dmitry.
> >>>
> >>
> >>
> >>
> >> --
> >> Xinchen Hui
> >> @Laruence
> >> http://www.laruence.com/
> >>
>
>

Re: [PHP-DEV] Re: Bug #70805 (Segmentation faults whilst running Drupal 8 test suite)

[Paul Dragoonis]

Hey,

Looking at the patch, the changes to zend_vm_def.h and zend_vm_execute.h
are duplicated in 10 locations. I'm wondering if we can consolidate this
into maintainable function/macro to handle this?

On Wed, Nov 4, 2015 at 1:58 AM, Xinchen Hui  wrote:

> Hey:
>
>
>
> On Wed, Nov 4, 2015 at 3:58 AM, Dmitry Stogov  wrote:
>
> > Hi,
> >
> > I think, I found the root problem of
> https://bugs.php.net/bug.php?id=70805
> >
> > unset($a) or unser($GLOBAL["a"]) triggered GC and destructors calls that
> > tried to release the same global variable $a  once again. As result it's
> > reference counter was decremented twice and this caused use-after-free,
> > double-free, etc.
> >
> > The proposed cumulative fix for all related problems:
> >
> > https://gist.github.com/dstogov/7aa9d24876e2b3fce8c5
> >
> > Xinchen, could you please review and verify this once again,
> > then add necessary tests and commit.
> >
> No problem, all issues we met are resovled , thanks :)
>
> tested and committed.
>
> and aslo thanks the fabian who provides us ssh access to a reproducible box
> (it's really hard to reproduce locally)
>
> thanks!
>
> >
> > Thanks. Dmitry.
> >
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>

Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause confuson

[Paul Dragoonis]

On Mon, Oct 12, 2015 at 8:23 PM, Andrea Faulds  wrote:

> Hi,
>
> As PHP 7 currently is, if you write this:
>
> public function foo(): integer {
> return 12;
> }
> $bar = foo();
>
> you'll get the following error:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, integer returned
>
> Similarly, if you were to write this:
>
> public function foo(): boolean {
> return true;
> }
> $bar = $foo();
>
> you'd get this:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of boolean, boolean returned
>
> These are confusing and unhelpful error messages. The long-form names of
> types (integer, boolean) aren't accepted as type hints, only their
> short-form names (int, bool) are. Yet we didn't reserve the names 'integer'
> and 'boolean' so we could produce a helpful error message, so anyone who
> types these long names will have them interpreted as type hints for (likely
> non-existant) classes named 'integer' or 'boolean' respectively. That
> produces confusing error messages on its own, but worse, type hint errors
> use 'integer' and 'boolean' to describe the types of values expected or
> given. Together, these two issues mean you get the two incredibly confusing
> error messages above.
>
> This is not kind to the users of PHP. It will cause unneeded confusion.
> This isn't even a theoretical case, that first example was based on a real
> StackOverflow question.[0] Mistakenly typing 'integer' or 'boolean' instead
> of 'int' and 'bool' is not at all an unlikely error, especially since the
> PHP manual uses these in some places (we should probably fix that at some
> point, and make it use PHP's actual syntax for return types and variadics,
> but I digress...), and since the aforementioned type error messages use
> them.
>
> To avoid confusion, I would like it if we reserve 'integer' and 'boolean'
> alongside 'int' and 'bool', and make them produce an error if used. This
> would catch out mistakes with people writing the wrong name for the type
> hint, and as a bonus would prevent people from misreading typehints for
> classes which actually have thse names, as no class with that name would be
> allowed. However, we're getting close to release and this might force some
> people to rename classes again if changed, causing disruption, so we might
> not be able to do this.
>
> Alongside or instead of that, though, we can do two other things to make
> this situation better.
>
> First, we could make type error messages use 'int' and 'bool'. This feels
> somewhat wrong to me since integer and Boolean are the proper English names
> for the types. But we do use the short names in some other places, like
> var_dump, so this isn't so bad. This way, we get this slightly clearer
> error:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, int returned
>
> Second, we could add a helpful note to the TypeError message when the type
> hint is for a class named 'integer' or 'boolean' and the value passed was
> an integer or Boolean, respectively. My patch (based on Anthony's original)
> for the earlier Scalar Type Hinting with Cast RFC did this. This would make
> things even clearer:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> instance of integer, int returned (did you mean to use the type hint 'int'?)
>
> Even if we can't reserve the names, I hope we can do the two other
> suggestions in time for release.
>
> By the way, this situation is at least partly my fault. For PHP 7 I fixed
> zend_parse_parameters and userland type hint errors consistent with regard
> to type names: always 'integer', never 'long' (which only ever occured for
> the expectation, not what was actually given, bizarrely), and also always
> 'float', never 'double'. I also made sure is_int was an alias of is_long
> and not vice-versa. Alas, I made the mistake of picking 'int' over
> 'integer' and 'bool' over 'boolean'.
>
> Anyway, can we do something about this soon?
>
> Thanks!
>
> [0]
> http://stackoverflow.com/questions/32665818/php-7-return-type-declarations-fatal-error
>
>
Hi Andrea,

Can you go ahead and make a branch/PR to add these type aliases in? There's
no right or wrong answer to 'int' versus 'integer', so allowing devs to
continue to use either will be welcoming.



> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

[PHP-DEV] Fwd: please stop the spam on php-webmaster

[Paul Dragoonis]

I need someone to turn off the php-webmaster mailer, like now.

I tried to change author info on commits i've made - which worked fine -
but then blew up the mailer.

I tested this on other github repositories and was like a transparent
change, all is fine, unless clearly there's a mailer connected to your repo
and it goes nuts.

Can someone please help!, I'm literally sitting here watching all the
emails rolling in and can't do anything about it :-(

Many thanks,
Paul

Re: [PHP-DEV] PDO Oracle driver

[Paul Dragoonis]

+1 from me. If nobody is maintaining it then it's a big risk. It should be
brought back in when there's people to maintain it.

On Wed, Apr 22, 2015 at 10:42 AM, Marco Pivetta  wrote:

> Absolutely +1 - most developers are dragged into using the PDO Oracle
> driver by "hope" (since they find the docs), and then they get to know the
> sad truth about it...
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 22 April 2015 at 10:40, Stelian Mocanita 
> wrote:
>
> > Hello internals,
> >
> > I would like to ask what on your thoughts on removing the Oracle drive
> for
> > PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php
> )
> > at least since it's been experimental for a long time now, and it has
> long
> > standing open bugs, such as:
> >
> > https://bugs.php.net/bug.php?id=37706
> > https://bugs.php.net/bug.php?id=46728
> > https://bugs.php.net/bug.php?id=60994
> >
> > I know that the extension is marked as experimental already but based on
> > the current status, it's not even that and a significant amount of basic
> > functionality is broken.
> >
> > Regards,
> > Stelian
> >
>

Re: [PHP-DEV] password_hash() deprecate salt option - thoughts?

[Paul Dragoonis]

On Tue, Mar 31, 2015 at 7:49 PM, Anthony Ferrara 
wrote:

> All,
>
> Ever since we introduced password_hash() in 5.5, I've been watching
> its usage as much as possible. I've setup google alerts and such, as
> well as auditing implementations I've found on github to try to
> understand how it's used.
>
> One thing has become abundantly clear to me: the salt option is
> dangerous. I've yet to see a single usage of the salt option that has
> been even decent. Every usage ranges from bad (passing mt_rand()
> output) to dangerous (static strings) to insane (passing the password
> as its own salt).
>
> I've come to the conclusion that I don't think we should allow users
> to specify the salt. The crypt() API still exists if users have a need
> to generate their own salt. Having it in the simplified API is simply
> adding a risk factor without any significant justification.
>
> So I'd like to hear your thoughts about raising E_DEPRECATED when the
> salt option is specified in 7.0, with ultimately removing the option
> in a later version.
>
> Additionally, I know this is after the RFC freeze deadline, so if you
> want to postpone the deprecation to 7.1, that's fine. I just think
> it's worth discussion (and if there's consensus to put it in 7.0, then
> great).
>
> Thanks,
>
> Anthony
>

No objections here. You're going with your gut on this and it seems like a
good call. We did make a freeze and although I'd like it in 7.0 we should
probably stick to our process here and put it in 7.1.

To be fair, there's always a quick *.1 release anyway once we find
real-world bugs that need patching quickly ;-)



>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC][VOTE] Scalar Type Declarations v0.5

[Paul Dragoonis]

Thanks for your work on this Anthony.

On Thu, Feb 26, 2015 at 2:58 PM, Anthony Ferrara 
wrote:

> All,
>
> I have opened voting on Scalar Type Declarations v0.5. Please cast your
> vote.
>
> https://wiki.php.net/rfc/scalar_type_hints_v5#vote
>
> The vote will remain open until March 13th, 2015 or until the date a
> competing RFC closes voting, whichever is later.
>
> Thanks
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC] [VOTE] Parameter skipping RFC

[Paul Dragoonis]

I see a LOT of "no" votes against this RFC but can't find the thread
outlining the reasoning for such resistence.

Could someone link me to this somehow?

On Sat, Feb 21, 2015 at 1:43 PM, Pascal Martin, AFUP <
mail...@pascal-martin.fr> wrote:

> Le 08/02/2015 09:14, Stanislav Malyshev a écrit :
>
>> I'd like to announce a vote on parameter skipping RFC:
>> https://wiki.php.net/rfc/skipparams
>>
>
> Hi,
>
> After discussing this RFC with other people at AFUP, we would be -1.
>
> Basically, even though not having to specify the default-value for some
> parameters could be useful in some situations, this approach doesn't "feel
> right" and we would really prefer something like named-parameters (even if
> this RFC is not incompatible with named-parameters and they most likely
> won't make it for PHP 7.0).
>
> Thanks
>
> --
> Pascal MARTIN, AFUP - French UG
> http://php-internals.afup.org/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

[Paul Dragoonis]

On Tue, Feb 10, 2015 at 11:36 PM, Leigh  wrote:

> On 10 February 2015 at 23:29, Paul Dragoonis  wrote:
> > It's common sense that if something receives significant resistance then
> > there's usually a good reason for it and it shouldn't be ignored
> regardless
> > of how mathematically accurate it may seem to exclude it. Let's keep
> MSSQL
> > in.
>
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extmssql
>
> Where is the significant resistance?
>

The original email said "17:13" i.e: I guess the mail was wrong then.

Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

[Paul Dragoonis]

On Tue, Feb 10, 2015 at 11:14 PM, Kalle Sommer Nielsen 
wrote:

> Hi Paul
>
> 2015-02-10 23:59 GMT+01:00 Paul Dragoonis :
> >
> > Did you accidentally miss out mssql? it resultes in significant
> resistance
> > to leave core, such as mcrypt and ignoring mathematical numbers, from a
> > practical basis I'd like to see mssql kept in core. Who's with me ?
>
> I'd like to see mssql kept as well, only makes more sense as we also
> have pdo_dblib. I wouldn't mind looking into some fixes to it or
> porting it once I get my FreeTDS or ntwdblib configuration setup here,
> as there is a fair bit of cleanup I'd like to do with it.
>
>
>
It's common sense that if something receives significant resistance then
there's usually a good reason for it and it shouldn't be ignored regardless
of how mathematically accurate it may seem to exclude it. Let's keep MSSQL
in.


>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>

Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

[Paul Dragoonis]

On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski 
wrote:

> Hi,
>
> the voting on the removals in PHP7 in hereby finished. The results are
>
>
> item   yes:no
>
> sapi/aolserver 32:0
> sapi/apache32:0
> sapi/apache_hooks  31:0
> sapi/apache2filter 23:1
> sapi/caudium   30:0
> sapi/continuity28:0
> sapi/isapi 28:0
> sapi/milter10:9
> sapi/phttpd26:0
> sapi/pi3web24:0
> sapi/roxen 23:0
> sapi/thttpd25:0
> sapi/tux   25:0
> sapi/webjames  25:0
> ext/imap   14:19
> ext/mcrypt 15:18
> ext/mssql  17:13
> ext/pdo_dblib  4:18
> ext/sybase_ct  17:1
>
> As most of the items are considered to be removed, the ones to stay
> untouched by the 50%+1 requirement are
>
> ext/imap
> ext/mcrypt
> ext/pdo_dblib
>

Did you accidentally miss out mssql? it resultes in significant resistance
to leave core, such as mcrypt and ignoring mathematical numbers, from a
practical basis I'd like to see mssql kept in core. Who's with me ?


>
> I'm going to implement and tag the changes considered ASAP. Regarding the
> stuff to considered to be removed from the core - if there are some
> supporters, the sources will be made available in the git tag. They can be
> anytime ported to PHP7 and possibly resurrected.
>
> Regards
>
> Anatol
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] What do we need strict scalar type hints for?

[Paul Dragoonis]

Hi Dmitry,

It's preferred to have flexible scalars, that way we can interchange
between a numerical string or an integer.

Over defining on such things loses the powerfulness of PHP. So scalar
typehints are detrimental rather than useful. Saying something is a scalar
or not, is useful however! :)

A use case would be where scalar type hints are detrimental are:

I implement an API that returns integers for entity ids, like 2,3,4,5,6.
and my web-frontend handles this fine because it's a scalar. Then, you want
to convert entity ids to  UUID. This would break your entire web frontend
application since it's no longer "integer" whereas the concept of $id is
good enough.

Did this make sense?

TL;DR - I am against such proposals.

Many thanks,
Paul





On Mon, Feb 2, 2015 at 9:12 AM, Dmitry Stogov  wrote:

> hi,
>
> could you please write down few use cases, when strict scalar type hints
> are really useful.
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

[Paul Dragoonis]

On 27 Jan 2015 19:49, "Stanislav Malyshev"  wrote:
>
> Hi!
>
> >>> Cons
> >>>  - Existing code modifications. (It's E_DEPRECATED. User may ignore.)
> >>>  - (Please point it out more disadvantages)
>
> I think removing or disrupting functions without a very good reason
> (such as, functionality going away or this function is abused or is
> broken in many use cases) is wrong. These functions don't seem broken,
> they just do something that you can do in another way. I don't think it
> is necessary to deprecated them.

I share the same mindset as Stas.

Let's work on resolving bugs instead of breaking BC ? :)

>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Re: [VOTE] Remove hex support in numeric strings

[Paul Dragoonis]

On 26 Jan 2015 20:02, "Nikita Popov"  wrote:
>
> On Sat, Jan 17, 2015 at 8:40 PM, Nikita Popov 
wrote:
>
> > Hi internals!
> >
> > The RFC proposing to remove support for hexadecimal strings in
> > is_numeric_string() is now in voting:
> >
> > https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings
> >
>

I always hated using is_numeric_string() because of the size and complexity
of it.

Removing this use case will make it smaller I hope, but probably not less
crazy :)

>
> Reminder: This vote closes tomorrow.
>
> Nikita

Re: [PHP-DEV] [RFC] Vote results for default ctors RFC

[Paul Dragoonis]

Hi Stas,

Maybe a cool wiki feature addition is: once people vote they could
optionally leave a comment right there on the wiki, which we could collect
and read. Thoughts?

Here's my feedback for you on why i voted No.

1) It felt a bit too "magic" for me, with no real gain from an internal or
userland perspective.

2) I don't see a flood of people coming to the mailing list complaining
about this feature, so I'm not compelled to want it in the language.

As always, thanks for your efforts.



On Sun, Jan 25, 2015 at 8:07 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> The vote for RFC https://wiki.php.net/rfc/default_ctor has been
> concluded, with the result of 27 vs. 20. Since 2/3 majority is required
> for acceptance, the RFC has been declined.
>
> I am a bit disappointed by the result, as I think it would be a good
> change, but I am much more disappointed by the fact that that 20 people
> voted against it and not even half of them - I would say maybe 1/5 of
> them - chose to participate in discussion even minimally and explain
> what is wrong with it in their opinion. I understand when everybody
> agrees there's no need of the flood of +1s, vote is enough, but
> disagreement by its nature is more diverse. I think not bothering to
> discuss and then just voting "no" with no explanation is not how the
> healthy RFC process should be working.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC][VOTE] Turn gc_collect_cycles into function pointer

[Paul Dragoonis]

On 22 Jan 2015 08:57, "Benjamin Eberlei"  wrote:
>
> On Wed, Jan 7, 2015 at 8:33 PM, Benjamin Eberlei 
> wrote:
>
> > Hello everyone,
> >
> > After discussion I am putting the RFC on turning gc_collect_cycles into
a
> > function pointer to vote:
> >
> > https://wiki.php.net/rfc/gc_fn_pointer
> >
> > Votes will end on 2015-01-21 19:31 (in 14 days).
> >
>
> Sorry, I forgot to send a reminder, but given the results of 18-0 I think
> this is ok.
>
> The gc_fn_pointer RFC was accepted with 18-0! Thanks everyone :-)

Woohoo! :)

>
> >
> > The discussion feedback on PHP 7 extension API refactoring was
> > incorporated in the RFC with a proposal to include the function pointer
> > AS-IS and make it part of a potential refactoring later.
> >
> > greetings
> > Benjamin
> >
> >
> >

Re: [PHP-DEV] Improvements to Hastable Bucket structure

[Paul Dragoonis]

On 22 Jan 2015 06:43, "Benjamin Coutu"  wrote:
>
> Hi,
>
> Currently a hashtable bucket has to store both, the numeric index "h" and
a potential pointer to a string key "key".
>
> There is room for improvement here because "h" and "key" are conceptually
mutually exclusive. I therefore propose to unionize "h" and "key" to
effectively save the overhead of having to reserve space for both.

This conceptually makes sense if you I deed just need one or the other but
not both.

Have you implemented this yet ? Have you benchmarked it ?

>
> Now, in order to still be able to distinguish between an integer key and
a pointer to a string key, one could use either of two approaches.
>
> === 1. Use flags of embedded zval (maybe _zval_struct.u1.v.*) ===
>
> If the is-key-flag is set in the embedded zval then its a string key, if
not then its an integer. This is of course only possible if _zval_struct.u1
is usable for this (I could not quickly tell).
>
> === 2. Pointer tagging ===
>
> On a 64/32-bit machine all pointers will be aligned to 8/4 bytes meaning
that their last 3/2 bits will always be zero. We can exploit this to
effectively store information about the pointer in those bits.
>
> We will use the last bit to distinguish between a pointer and an
63/31-bit integer, and the second last bit to distinguish between a pointer
to a string key or pointer to the overflowing integer (64/32 bit). Here is
a (8-bit) sample:
>
> LLL1: integer (effectively 63/31)
> PP00: pointer to zend_string (string key)
> PP10: pointer to zend_ulong (in case integer key is > 63/31 bit)
>
> One will then be able to use simple shifting and bitwise operations to
extract the correct meaning.
>
> Please let me know your thoughts!
>
> Cheers,
>
> Ben
>
> --
>
> Benjamin Coutu
> Zeyon Technologies Inc.
> http://www.zeyos.com
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC] jsond

[Paul Dragoonis]

On 11 Jan 2015 17:28, "Jakub Zelenka"  wrote:
>
> Hi,
>
> This rfc about replacing json with jsond is under discussion.
>
> https://wiki.php.net/rfc/jsond
>
> I have finally done some benchmarks. You can find a link in the RFC.
>
> It's been extensively tested for the last few months and there is just one
> BC that I'm aware of.
>
> The new parser accepts only float number that conforms to RFC 7159 . This
> is also not consistent between decoding float number that are and are not
> in the array/object ( there are two conversion rules). The following
> formats are rejected:
>
> 1. parsed at the top level: 07, 0xff, .1, -.1
> 2. parser by JSON_Parser: [1.], [1.e1]
>
> I feel that this was a bug in the new parser and we must conform to RFC
> 7159 !

I was just thinking about your jsond work just yesterday actually.

I feel if we need to make a minor BC break to get this in, then go with it
for PHP 7.

I do think that if it's possible for you to detect when users supply this
invalid float input that you would throw an informative exception to help
people with the transition over to PHP7.

What's the rest of the team's thoughts on this ?

>
> Cheers
>
> Jakub

Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)

[Paul Dragoonis]

On 10 Jan 2015 01:10, "Sara Golemon"  wrote:
>
> On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye  wrote:
> > The fact that hhvm implements a significant part of the extensions (or
> > other areas) using PHP+additional syntax as well as adding cleaner
> > APIs or mechanisms for the C parts only confirms me one thing: the
> > very 1st problem we have to solve is to ease the extension creation,
> > by drastically changing the internals APIs & tools. Bundling script
> > does not help here, we are using a scotch tape to repair something
> > that should have been replaced or redesigned since long already. I am
> > not blaming anyone, the engine design, historically, does not make
> > such changes easy.
> >
> Funny to see you mention this.  I literally just pulled together a
> meeting today to discuss HHVM's admittedly unstable extension API.
> One idea to emerge from this was to design a new extension API
> agnostic of underlying implementation.  An API which, if done right,
> could be adapted equally to both PHP7 and HHVM *and* provide the
> opportunity to introduce PHP5 shims so that a single extension could
> be written to function identically under any PHP runtime, and any
> version. If done right, could make extensions not just source
> compatible, but *binary* compatible as well.  The engine details can
> change, but the public-facing extension API could offer a consistent
> way of doing the one and only thing that extensions should have to do:
> Glue PHP into external libraries.
>
> That's a bit pie in the sky, I'll admit, but wouldn't that be cool?
> Fact is, JNI does this for Java already, so there's precedence to
> learn from.  Heck, we're actually halfway there with HHVM's
> "ext_zend_compat" layer, which makes PHP extensions (mostly) source
> compatible with HHVM.
>
> While I could work on this in the dark, manipulating HHVM's APIs with
> one hand and adding proxy interfaces to PHP (as an extension) with the
> other, I'd much rather have involvement from others.
>
> What do you think?

Hi Sara,

Somewhat Pie in the sky but at the same time also achievable with good
planning and design. I'd support this definitely and this abstraction layer
would solve constant maintainability of extensions by not having to update
themselves constantly to support latest versions of PHP due to a lack of
abstraction.

Did that make sense ?

>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Bugfest

[Paul Dragoonis]

Come up with a way to incentivise people to fix bugs.

My previous suggestion was to have a contributors page and it will rank
people based on bug fixes.

I'd be happy to work on this with someone.
On 28 Dec 2014 19:16, "Levi Morrison"  wrote:

> I have committed a fix for one bug and closed another bug report
> because of this thread. I will continue to look at bugs but I wanted
> to spread some encouragement.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [PATCH] Consistent type names in error messages

[Paul Dragoonis]

On 21 Dec 2014 13:25, "Andrea Faulds"  wrote:
>
>
> > On 20 Dec 2014, at 15:50, Andrea Faulds  wrote:
> >
> >
> >> On 14 Dec 2014, at 18:35, Andrea Faulds  wrote:
> >>
> >> I’ve made a patch which makes zend_parse_parameters and userland type
hints consistently show “integer” and “float” rather than “long” and
“double”: https://github.com/php/php-src/pull/955
> >>
> >> I also wrote a GNU sed script which I used to update the tests:
https://gist.github.com/TazeTSchnitzel/c0d780466def9f226318
> >
> > Hi,
> >
> > Is anyone here opposed to this, or should I just merge it? I don’t
think it really needs an RFC. It doesn’t break BC.
> >
> > Thanks.
>
> Hey,
>
> I’ve merged the patch into master, PHP 7 will have consistent type names
in its error messages. :)

Thanks for the patch and the other contribs you've been doing lately.

>
> Thanks.
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols

[Paul Dragoonis]

Hi Francois,

It's too big of a BC change firstly.

Secondly it has no language benefit or developer benefit.

The only benefit is case correctness which is a nice to have. Making sure
existing code works is a must have.

Cheers,
Paul
 On 20 Dec 2014 22:01, "F & N Laupretre"  wrote:

> Hi,
>
>
>
> I don't know if this was discussed before. So, tell me what you think
> before
> I write an RFC.
>
>
>
> I would like to propose that namespaces, functions, and classes become
> case-sensitive (constants are already case-sensitive). Actually, I never
> understood why they are case-insensitive. Even if the performance gain is
> negligible, I think it could be the right time to question this.
>
>
>
> Regards
>
>
>
> Francois
>
>

Re: [PHP-DEV] [VOTE][RFC] Native TLS

[Paul Dragoonis]

On Wed, Dec 17, 2014 at 8:27 PM, Anatol Belski 
wrote:
>
> Hi,
>
> On Wed, December 10, 2014 20:04, Anatol Belski wrote:
> > Hi,
> >
> >
> > hereby the voting on https://wiki.php.net/rfc/native-tls#vote is opened.
> > The vote starts on 12/10/2014 at 21:00 CET and ends on 12/17/2014 at
> > 21:00
> > CET.
> >
> >
> this RFC was accepted, thanks everyone! I'm going to merge it next days.
>

Thank you for this improvement, it's appreciated.


>
> Regards
>
> Anatol
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE][RFC] Native TLS

[Paul Dragoonis]

On Wed, Dec 10, 2014 at 8:46 PM, Dmitry Stogov  wrote:
>
> +1
>
> the patch is great.
> It doesn't affect non-ZTS build at all.
> ZTS build became even a bit faster. :)
>


> And we finally will able to forget about TSRMLS_ macros :)
>

Say what? this is music to my ears :) Thanks for the patch.


>
>
> Non-ZTS ZTS
> master native-tls master native-tls  bench.php [sec] 1.193 1.195 1.313
> 1.299  micro_bench.php
> [sec] 6.008 6.064 7.470 6.786  Wordpress-3.6 -T 1000 [sec] 13.308 13.293
> 14.997 14.611
>
>
>
>
>  bench.php [Mops] 7,055 7,055 7,885 7,342  Wordpress-3.6 -T 100 [Mops]
> 3,093
> 3,093 3,743 3,483
> Mops - millions of instruction fetches measured using callgrind (the less
> the better)
>
> The solution requires minor changes in every third party extension, but
> it's really small cost for significant step forward.
>
> Thanks. Dmitry.
>
> On Wed, Dec 10, 2014 at 10:04 PM, Anatol Belski 
> wrote:
>
> > Hi,
> >
> > hereby the voting on https://wiki.php.net/rfc/native-tls#vote is opened.
> > The vote starts on 12/10/2014 at 21:00 CET and ends on 12/17/2014 at
> 21:00
> > CET.
> >
> > Regards
> >
> > Anatol
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] Zend Engine 3

[Paul Dragoonis]

On 24 Nov 2014 12:32, "Paul Dragoonis"  wrote:
>
>
> On 24 Nov 2014 12:18, "Nikita Popov"  wrote:
> >
> > On Mon, Nov 24, 2014 at 1:10 AM, Andrea Faulds  wrote:
> >
> > > Good evening,
> > >
> > > Since phpng, int64, and perhaps other future changes in PHP 7 are a
pretty
> > > big change, I think we ought to bump the major version number of the
Zend
> > > Engine, from Zend Engine 2 to Zend Engine 3.
> > >
> > > I have a pull request open which would do this, although it needs
updating
> > > to correct extensions checking for ZEND_ENGINE_2:
> > > https://github.com/php/php-src/pull/829
> > >
> > > Are there any objections to the idea? I realise work on the engine
isn’t
> > > done, but that doesn’t mean we can’t name the new version. After all,
we’ve
> > > named PHP 7, and it doesn’t exist yet, either.
> > >
> > > Thoughts?
> > >
> >
> > Why do we need this define at all? Imho extensions should be checking
> > against the API version, rather than a ZEND_ENGINE_N constant. This is
more
> > precise (it's not like extension code stays the same between minor
> > versions), but the ZEND_ENGINE_N constant also has the problem that it
> > targets only 5.x, even though the code it guards would usually be
relevant
> > to 7.x as well.
>
> Paying to way for now asking someone to know the specific individual API

On my phone sorry. This should be: "Paving the way to not asking someone"

versions and their features, the convenience of saying "I know ZE 3
supports this and ZE2 does not" would be a worth while addition.
>
> Especially for newcomers to ext dev.
>
> >
> > Nikita

Re: [PHP-DEV] Zend Engine 3

[Paul Dragoonis]

On 24 Nov 2014 12:18, "Nikita Popov"  wrote:
>
> On Mon, Nov 24, 2014 at 1:10 AM, Andrea Faulds  wrote:
>
> > Good evening,
> >
> > Since phpng, int64, and perhaps other future changes in PHP 7 are a
pretty
> > big change, I think we ought to bump the major version number of the
Zend
> > Engine, from Zend Engine 2 to Zend Engine 3.
> >
> > I have a pull request open which would do this, although it needs
updating
> > to correct extensions checking for ZEND_ENGINE_2:
> > https://github.com/php/php-src/pull/829
> >
> > Are there any objections to the idea? I realise work on the engine isn’t
> > done, but that doesn’t mean we can’t name the new version. After all,
we’ve
> > named PHP 7, and it doesn’t exist yet, either.
> >
> > Thoughts?
> >
>
> Why do we need this define at all? Imho extensions should be checking
> against the API version, rather than a ZEND_ENGINE_N constant. This is
more
> precise (it's not like extension code stays the same between minor
> versions), but the ZEND_ENGINE_N constant also has the problem that it
> targets only 5.x, even though the code it guards would usually be relevant
> to 7.x as well.

Paying to way for now asking someone to know the specific individual API
versions and their features, the convenience of saying "I know ZE 3
supports this and ZE2 does not" would be a worth while addition.

Especially for newcomers to ext dev.

>
> Nikita

Re: [PHP-DEV] New Standardized HTTP Interface

[Paul Dragoonis]

On 30 Oct 2014 19:03, "Sherif Ramadan"  wrote:
>
> Hello Internals,
>
> I've been meaning to write up a full-blown RFC for introducing a new
> standardized HTTP interface for PHP core for some time now. I figure now
> with PHP 7 on the road map this might be a good time to start this
> discussion since it involves breaking some backwards compatibility that
may
> have been out of the question in PHP 5.
>
> I've started a draft RFC, but please be patient as this is a working in
> progress, here https://wiki.php.net/rfc/http-interface on the wiki.
>
> The point here is to allow users to implement their own HttpRequest and
> HttpResponse classes that can deal directly with the raw request/response
> messages in any way the user deems fit. This alleviates cases like "what
> about when I want to have $_PUT or $_DELETE" and removes the ambiguity of
> the $_POST, $_GET superglobals to a more conforming way of handling the
> messages.
>
> Since it's an interface, it only dictates the facilitation of PHP's
> built-in functionality and the user's desired implementation, but no the
> implementation itself. To remove all confusion, consider the way an HTTP
> message actually looks.
>
> GET /foo?bar=1 HTTP/1.1
> Host: foobar.com
>
> baz=2
>
> Instead of treating this with current $_GET, $_POST, let's consider for a
> moment how we might treat it in an HttpRequest object:
>
> If the HttpRequest class implements an HttpParameters object that parses
> and treats the entire HTTP request line as a string of parameters we could
> accomplish the following...
>
> var_dump(HttpRequest::$parameters->bar); // int(1)
> var_dump((string) HttpRequest::$parameters); // string(6)"?bar=1"
>
> Now consider how the body can be treated...
>
> echo HttpRequest::$body; // baz=2
> echo HttpRequest::$body->baz; // 2
>
> Since the HttpRequest object can lazily parse the body it can also lazily
> apply custom filters directly to the request variables and parameters...
>
> For example, say you wish to treat baz only as an integer? This can be
> easily accomplished by setting the filters directly in the HttpRequest
> object and upon access the filter is directly applied to chosen variables.
> This also alleviates the need to worry about overwriting superglobal
> variables or having to copy from them. So from an efficiency stand-point
> this approach works much better. It also allows you to separate clearly
> between HTTP request parameters and HTTP request body as well as the HTTP
> request method. Since the request object should be capable of handling
> callbacks for each method to apply different sets of filters or rules on
> treating the request body given different request methods this could prove
> a lot more useful than existing techniques applied directly in PHP with
> php://input, for example.
>
> We don't need to copy the internal stream and we don't need to modify or
> copy superglobals around to different parts of our code.
>
> I'm in the process of writing up a cleaner implementation to introduce in
> the RFC, but in the mean time I'd like to open up to discussion and see
> what others think or how they feel we might approach this problem more
> cleanly.
>
> Thanks,
> Sherif

This is clearly a responsibility of PHPFIG for interface recommendations
and not the responsibility of the core language.

Re: [PHP-DEV] Improve PHP 7 serialization

[Paul Dragoonis]

I clearly didn't google, it would be interesting to see comparisons of high
speed PHP serialization libraries. I for one would be happy, in PHP 7, to
break BC serialization syntax in favour of putting in a much faster
serializer by default. Similar scenario to putting in Zend OpCache by
default instead of APC.

Pierre, do you see merit on including  by default in PHP7 ?


On Tue, Sep 23, 2014 at 12:57 PM, Pierre Joye  wrote:

> http://pecl.php.net/package/msgpack
>
> On Tue, Sep 23, 2014 at 1:34 PM, Leigh  wrote:
> > On 23 September 2014 12:22, Paul Dragoonis  wrote:
> >> Write an extension for it then, also share your benchmarks :)
> >>
> >
> > Why go to all that trouble, 10 seconds on Google and we have:
> >
> > https://github.com/msgpack/msgpack-php
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>

Re: [PHP-DEV] Improve PHP 7 serialization

[Paul Dragoonis]

Write an extension for it then, also share your benchmarks :)

On Tue, Sep 23, 2014 at 12:17 PM, Park Framework 
wrote:

> Performance testing, Msgpack VS Igbinary
>
> igbinary: -20% slower, data size ~5%
>
> Advantage Msgpack, he works fast, and this format understood by many
> technologies - Java, Python, Lua in Redis.
>
>
> 2014-09-23 12:20 GMT+03:00 Paul Dragoonis :
> > Hi ,
> >
> > Backwards compatibility is one hurdle, but if you wipe all your
> serialised
> > data then begin to re-serialise using the new approach then you're fine.
> >
> > As for what to use msgpack or igbinary, well there's already good support
> > for igbinary in PHP thanks to Pierre and others. You should benchmark
> > igbinary vs msgpack and come back with your findings if we're to evaluate
> > alternative serialization libraries.
> >
> > Many thanks,
> > Paul
> >
> >
> > On Tue, Sep 23, 2014 at 12:23 AM, Park Framework <
> park.framew...@gmail.com>
> > wrote:
> >>
> >> PHP serialization is slowest in PHP Session, clients NoSQL, ...
> >> I would like to have in PHP 7, a new serialization algorithm or custom
> >> handler to serialize.
> >>
> >> My opinion is that the best choice is to use msgpack, it is
> >> +110% faster
> >> -30% data size
> >>
> >> HHVM discussed this issue, but all boils down to backward compatibility
> >> with PHP
> >> https://github.com/facebook/hhvm/issues/2654
> >>
> >> What do you think about this, maybe it's time to change the old
> >> algorithm serialization, on something better?
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
>

Re: [PHP-DEV] Improve PHP 7 serialization

[Paul Dragoonis]

Hi ,

Backwards compatibility is one hurdle, but if you wipe all your serialised
data then begin to re-serialise using the new approach then you're fine.

As for what to use msgpack or igbinary, well there's already good support
for igbinary in PHP thanks to Pierre and others. You should benchmark
igbinary vs msgpack and come back with your findings if we're to evaluate
alternative serialization libraries.

Many thanks,
Paul


On Tue, Sep 23, 2014 at 12:23 AM, Park Framework 
wrote:

> PHP serialization is slowest in PHP Session, clients NoSQL, ...
> I would like to have in PHP 7, a new serialization algorithm or custom
> handler to serialize.
>
> My opinion is that the best choice is to use msgpack, it is
> +110% faster
> -30% data size
>
> HHVM discussed this issue, but all boils down to backward compatibility
> with PHP
> https://github.com/facebook/hhvm/issues/2654
>
> What do you think about this, maybe it's time to change the old
> algorithm serialization, on something better?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Making parse_ini_*() aware of types

[Paul Dragoonis]

Seems like a no brainer and since its gone through voting then you could go
ahead with it.
On 30 Aug 2014 15:37, "Tjerk Meesters"  wrote:

> Hi internals,
>
> I was going through the bug list and found this report:
>
> https://bugs.php.net/bug.php?id=38409
>
> It discusses the fact that `parse_ini_file()` and `parse_ini_string()`
> throw away type information; for instance, the flag “on” doesn’t translate
> into a bool(true) but string(“1”).
>
> The report has had 21 votes and an average score of 4.3 +- 0.7, so it
> seems to have some traction with users.
>
>
> Simply changing this behaviour would cause BC, so I’ve found a way in
> which this can be solved with a separate scanner mode; e.g.:
>
> $data = parse_ini_file(‘/path/to/file’, true, INI_SCANNER_TYPED);
>
> A patch for the lexer can be found here, together with a simple test case:
>
>
> https://github.com/datibbaw/php-src/compare/php:master...datibbaw:ini-scanner-plus
>
> It currently distinguishes between booleans, numbers and NULL (it was
> mentioned in the ticket by someone else, not entirely sure of its
> usefulness, though). I haven’t benchmarked it, but the impact on
> performance should be quite minimal.
>
> Thoughts?
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Abstract Syntax Tree

[Paul Dragoonis]

On Wed, Aug 20, 2014 at 3:41 PM, Levi Morrison  wrote:

> On Wed, Aug 20, 2014 at 7:30 AM, Paul Dragoonis 
> wrote:
> > On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans  wrote:
> >
> >> Hi Nikita,
> >>
> >> I reviewed the AST RFC on my way to vote but there was something that
> >> wasn’t clear to me.
> >> This patch introduces some semantic/behavioral changes in addition to
> the
> >> AST.
> >> Are these as a side-effect of how AST was implemented? Or are they
> >> unrelated to the AST patch?
> >> I think some of them make sense but I’m having a bit of a hard time
> >> separating out the benefits of the AST (which I really like) and making
> >> other changes to semantics w/o really understanding if they are
> >> side-effects and we have no choice vs. we’re trying to solve for two
> >> separate items in one RFC.
> >> Any BC breaks here we think could bite us?
> >>
> >
> > Hi Nikita,
> >
> > I second some of Andi's concerns about behavioural changes, some things
> > working from right-to-left and not left-to-right. Are these things that
> we
> > can adapt the AST part or tweak another part to make this more consistent
> > with previous versions of PHP.
>
> I just had a chat with Paul about this, and there was a
> misunderstanding about what this RFC actually does regarding
> left-to-right evaluation on list() constructs. I also saw this
> misunderstanding in a few other places, so it seems to be a common
> misunderstanding.
>
> Under the proposed changes as well as in PHP 5.x, the end result of
> the following is the same:
>
> list($a, $b) = array(1, 2);
>
> $a will be 1 and $b will be 2. Again, this hasn't changed. The
> difference is that in PHP 5.x the variable $b will be assigned 2
> before $a is assigned 1; under these changes $a will be assigned 1
> first and then $b will be assigned 2.
>

I'm happy with this behaviour and agree that the AST version is what I
would expect, my confusion was that I thought PHP 5.x was 1,2 and the AST
was 2,1 which it of course is not the case. Now you could see why I raised
concerns about this in the first place.


>
> This really only affects strange situations, such as ones listed in the
> RFC.
>

Re: [PHP-DEV] [VOTE] Abstract Syntax Tree

[Paul Dragoonis]

On Wed, Aug 20, 2014 at 2:57 PM, Nikita Popov  wrote:

> On Wed, Aug 20, 2014 at 3:30 PM, Paul Dragoonis 
> wrote:
>
>> Hi Nikita,
>>
>> I second some of Andi's concerns about behavioural changes, some things
>> working from right-to-left and not left-to-right. Are these things that we
>> can adapt the AST part or tweak another part to make this more consistent
>> with previous versions of PHP. Improving consistency when changing
>> underlying parts is a good migration technique. Facebook done this when
>> they implemented HHMV, they didn't fix bugs but made a like-for-like stable
>> copy before tackling improvements.
>>
>> Do you feel it's an important goal to keep consistency from PHP 5.x to
>> PHP 7, with regards to the behaviour of syntax parsing/behaviour, or do you
>> feel that you can live with these non-BC changes?
>>
>> Many thanks,
>> Paul
>>
>
> Is there some *particular* change that concerns you? This is something
> that needs to be decided on a case-by-case basis. The RFC contains a list
> of changes. All of them are minor adjustments verging on bug fixes, which
> imho are all within the bounds of reasonable changes for a major version.
> However if you can provide argument why one of the listed changes is
> incorrect (as in, introduces less intuitive/consistent/... behavior) or has
> larger BC impact than anticipated, then I'm open to discussion that.
>

I will get back to you with some specific use cases that I see could be
potentially problematic and non-intuitive.


>
>
> Nikita
>

Re: [PHP-DEV] [VOTE] Abstract Syntax Tree

[Paul Dragoonis]

On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans  wrote:

> Hi Nikita,
>
> I reviewed the AST RFC on my way to vote but there was something that
> wasn’t clear to me.
> This patch introduces some semantic/behavioral changes in addition to the
> AST.
> Are these as a side-effect of how AST was implemented? Or are they
> unrelated to the AST patch?
> I think some of them make sense but I’m having a bit of a hard time
> separating out the benefits of the AST (which I really like) and making
> other changes to semantics w/o really understanding if they are
> side-effects and we have no choice vs. we’re trying to solve for two
> separate items in one RFC.
> Any BC breaks here we think could bite us?
>

Hi Nikita,

I second some of Andi's concerns about behavioural changes, some things
working from right-to-left and not left-to-right. Are these things that we
can adapt the AST part or tweak another part to make this more consistent
with previous versions of PHP. Improving consistency when changing
underlying parts is a good migration technique. Facebook done this when
they implemented HHMV, they didn't fix bugs but made a like-for-like stable
copy before tackling improvements.

Do you feel it's an important goal to keep consistency from PHP 5.x to PHP
7, with regards to the behaviour of syntax parsing/behaviour, or do you
feel that you can live with these non-BC changes?

Many thanks,
Paul



>
> Any insight would be much appreciated.
> Thanks!
> Andi
>
> On Aug 18, 2014, at 9:41 AM, Nikita Popov  wrote:
>
> > Hi internals!
> >
> > I've opened the vote on the Abstract Syntax Tree RFC:
> >
> >https://wiki.php.net/rfc/abstract_syntax_tree#vote
> >
> > Thanks,
> > Nikita
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Mutliple defaults in switch statements

[Paul Dragoonis]

On 12 Aug 2014 22:36, "Sara Golemon"  wrote:
>
> On Tue, Aug 12, 2014 at 10:08 AM, Andrea Faulds  wrote:
> > On 12 Aug 2014, at 17:53, Sara Golemon  wrote:
> >> Voting is open: https://wiki.php.net/rfc/switch.default.multiple#vote
> >
> > I’m all for this, but the *minimum* discussion period is *two* weeks.
> >
> The two-week period is advisory and we don't need to get hung up on
> process for the sake of process.  There's been no meaningful
> discussion in the past week because nobody thinks this is remotely a
> bad idea.  Hell, some have questioned why this was put into an RFC in
> the first place. (It's arguably a bug, since the existing behavior
> could never have been described as right or intentional).

I fully back this. It's literally a bug fix which has let slide for some
time now. It's clear from the voting results that the core community
support this.

Thanks Sara for supplying the patch.

>
> If you're so worried about violating RFC process, I can revoke it
> entirely and just commit it without voting, and I'd be completely in
> the right.  Or, we can apply a reasonable amount of process without
> getting hung up on seven days worth of... no discussion whatsoever.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Vote: Anonymous Classes

[Paul Dragoonis]

Hi Joe,

Thanks for your hard work on anonymous classes.

I voted no because I feel it's just adding more and more ways to achieve
similar results and the syntax is just more sugary fluff to allow people to
do things the wrong way.

We've had a lot of new features in recent versions, i.e: traits, so I
believe this isn't something PHP needs right now and PHP needs to focus on
bug fixing and solidifying what we have right now.

Thanks,
Paul


On Wed, Oct 9, 2013 at 8:58 AM, Joe Watkins  wrote:

> On 10/07/2013 11:20 AM, Peter Cowburn wrote:
>
>> On 7 October 2013 11:13, Joe Watkins  wrote:
>>
>>>
>>> Morning Chaps,
>>>
>>>  On the advice of many, I have restarted the vote, sorry for the
>>> inconvenience/confusion ...
>>>
>>
>>
>> https://wiki.php.net/rfc/**anonymous_classes#voting(re-link,
>>  for the lazy)
>>
>> The voting options changed from choosing a version ("5.6", "5.7") or
>> rejecting… too a much simpler, yes/no for sticking this into master.
>>  Which
>> branch/release the feature makes it into is something to be decided down
>> the line (ultimately, by the RMs).
>>
>>
>>
>>> Cheers
>>> Joe
>>>
>>>
>>>
>>  Morning All,
>
> To anyone who has voted or will vote no; if you have voted no but
> is something that could be done to the patch to change your mind, please do
> speak up :)
>
> If you voted/will vote no and there's nothing that can change your
> mind, I'd still be interested in hearing the reasoning ...
>
> This is a pretty quiet vote ... as this is the first RFC I have
> put forward, I'd like a bit more feedback so I can avoid the avoidable in
> the future ...
>
>
> Cheers
> Joe
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Maintaining Phar

[Paul Dragoonis]

+1


On Mon, May 27, 2013 at 11:41 AM, Sebastian Bergmann wrote:

> Am 27.05.2013 12:39, schrieb Michael Wallner:
> > All previous MAINtainers are gone and there does not seem to be a lot
> > of objection, so I'll start the +1s for a new & willing contributor:
>
>  +1 :)
>
> --
> Sebastian BergmannCo-Founder and Principal Consultant
> http://sebastian-bergmann.de/   http://thePHP.cc/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP 5.5 beta3 is here

[Paul Dragoonis]

Thanks for all your hard work Julien / David.


On Thu, Apr 11, 2013 at 9:50 AM, Julien Pauli  wrote:

> Hi Internals,
>
> PHP 5.5.0 Beta 3 has been released for testing. It fixes some bugs against
> beta 2.
> You'll find details in the NEWS file.
>
> The packages can be found at:
>
>   http://downloads.php.net/dsp
>
> and windows packages at
>
>   http://windows.php.net/qa
>
> Please test the release carefully and report any bugs.
>
> Our next beta is planned for April 25th.
> At this time, we are thinking the next beta (4th) should be the last one.
> RCs will follow.
>
> Thanks to all people that worked on the project to make this beta
> available.
>
> Regards
>   Julien and David
>

Re: [PHP-DEV] [RFC] Short syntax for anonymous functions

[Paul Dragoonis]

I also am not in favour of the syntax, it's too short and quirky. I'm
honestly fine with 'function()' it's very explicit


On Tue, Feb 19, 2013 at 1:20 PM, Anthony Ferrara wrote:

> Marcello,
>
>
> On Tue, Feb 19, 2013 at 7:57 AM, Marcello Duarte 
> wrote:
>
> > Inspired by Sara, here is another RFC, I finally got around to draft:
> >
> > https://wiki.php.net/rfc/short-syntax-for-anonymous-function
> >
> > Please feedback,
> > --
> > Marcello Duarte
> >
> >
> I like the concept. I dislike the syntax. It looks too much like a JSON
> object declaration, and it feels like it should be returning an object
> instead of a closure/anonymous function. Additionally, I don't like that
> it's also a closure. Short functions like this should be for simple
> functions...
>
> Perhaps:
>
> lambda $x: trim($x);
>
> $x: trim($x);
>
> Or something similar...
>
> Anthony
>

Re: [PHP-DEV] Re: O+ 1st results

[Paul Dragoonis]

On Fri, Feb 15, 2013 at 9:23 AM, Damien Tournoud  wrote:

> On Fri, Feb 15, 2013 at 9:54 AM, Pierre Joye  wrote:
> >
> > >>Mediawiki is slower because it does not support yet O+ for usercache,
> > >>along other things.
> > >
> > > Is the same the case with Symfony?
> >
> > no, MediaWiki caching modules only support APC or Wincache so far.
>
> As far as I understand, O+ doesn't have any user caching support, right?
>
> So the comparison needs to be with user caching disabled in Mediawiki
> when running with APC or Wincache.
>

Hi Damien,

No, O+ doesn't have user level caching, it's only for opcode caching. It
was discussed that APC should continue to provide user level caching.


>
> Damien
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] File system watcher/monitoring

[Paul Dragoonis]

On Thu, Feb 14, 2013 at 5:00 PM, Patrick ALLAERT wrote:

> 2013/2/14 Ivan Enderlin @ Hoa :
> > I have written: “On Linux, we have inotify (available in PHP through
> > pecl/inotify)”, so yup, I know for inotify :-). I propose to gather all
> > these API and give a proper one to the end-user.
>
> If you are doing so, I would suggest you to create this as a C
> library, that way you could bring that feature to any
> applications/languages and you would only have to create a bridge as a
> PECL extension.
>

and to carry on from Patrick's point, it would probably be cleaner to do it
this way so your library wouldn't need to work around PHP stuff.



>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] echo new SplFileObject(__FILE__);

[Paul Dragoonis]

I also agree that we don't need to fix this, nor break BC. It is confusing
as hell but it's there now and changing it would be more disruptive.

Is there a desire from anyone to gracefully throw E_DEPRECATED in a future
version of PHP 5.x when someone tries to __toString() the SplFileObject but
only get back a single line ?

That's the only "plan forward" I can see feasible if we decided to do
anything, otherwise we should move on.


On Wed, Jan 30, 2013 at 6:44 PM, Ferenc Kovacs  wrote:

> 2013.01.30. 19:16, "Stas Malyshev"  ezt írta:
> >
> > Hi!
> >
> > > But this isn't that strong of an argument, and I think that following
> > > what SplFileInfo does would be more sensible (echoing the filename),
> but
> > > I'm not sure change would worth breaking BC for.
> >
> > I don't see why it would be more sensible. It's different objects that
> > do different things - Info represents file name, more or less, while
> > Object represents file contents. I see no reason why it would only make
> > sense for Object to return filename, or why we should "fix" something
> > that is not broken.
>
> imo the toString should return something which represents the object and
> the filename satisfy that better than a "random" line from the file.
> but I agree that this isn't a real concern and doesn't need fixing.
>
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
>

Re: [PHP-DEV] echo new SplFileObject(__FILE__);

[Paul Dragoonis]

To be honest, it looks like __toString() was just added in there for the
sake of it without any real thought as to what casting an entier
SplFileObject to a string. This to me implies the entire object( i.e: the
entire file ) should be returned as a string rather than aliasing it to a
method because why would you cast something to a string if you can call
->current() anyway.

Since it's been baked into the object for some time now it can't even be
changed now.

I'd try to avoid this casting magic and stick with ->current() if you
actually mean it.

Thanks,
Paul Dragoonis.


On Wed, Jan 30, 2013 at 3:44 PM, hakre  wrote:

>
>
> - Ursprüngliche Message -
>
> > Von: Stas Malyshev 
> > Gesendet: 0:00 Mittwoch, 30.Januar 2013
> > Betreff: Re: [PHP-DEV] echo new SplFileObject(__FILE__);
> >
> >
> > __toString is mapped to current() for SplFileObject:
> > http://www.php.net/manual/en/splfileobject.current.php
> >
> > it's not documented for some reason, I think it makes sense to file a
> > docs bug on that.
>
> Thanks for your answer.
>
> I know that there is code in there that does this and I also got into the
> know that it is not properly documented.
>
> I just write this to clarify that I'm more interested in the why it has
> been coded that way.
>
> It does not make much *sense* to me and I want to learn more.
>
> Also I don't mean this explicit technically. I could blame the version
> control, pick the authors name and email that person; however some time has
> passed and more users are using it not only the original author so I ask in
> internals first. Just for clarification.
>
> -- hakre
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] new FTP function

[Paul Dragoonis]

An extra parameter is required in the above function, but you get the
point, i don't want to keep spamming the mailing list with corrections :-)


On Fri, Jan 18, 2013 at 3:30 PM, Paul Dragoonis  wrote:

> Revised function:
>
> function dir_exists($conn, $currentDir) {
> $list  = ftp_nlist($conn, '-dF '. $currentDir);
> return in_array($dir, $list);
> }
>
>
> On Fri, Jan 18, 2013 at 3:28 PM, Paul Dragoonis wrote:
>
>>
>> On Fri, Jan 18, 2013 at 3:18 PM, KISE  wrote:
>>
>>> $res  = ftp_nlist($this->conn_id, '-dF '. $dir);
>>>
>>
>> This could be done in two lines.
>>
>> function dir_exists($conn, $dir) {
>> $list  = ftp_nlist($conn, '-dF '. $dir);
>> return in_array($dir, $list);
>> }
>>
>
>

Re: [PHP-DEV] new FTP function

[Paul Dragoonis]

Revised function:

function dir_exists($conn, $currentDir) {
$list  = ftp_nlist($conn, '-dF '. $currentDir);
return in_array($dir, $list);
}


On Fri, Jan 18, 2013 at 3:28 PM, Paul Dragoonis  wrote:

>
> On Fri, Jan 18, 2013 at 3:18 PM, KISE  wrote:
>
>> $res  = ftp_nlist($this->conn_id, '-dF '. $dir);
>>
>
> This could be done in two lines.
>
> function dir_exists($conn, $dir) {
> $list  = ftp_nlist($conn, '-dF '. $dir);
> return in_array($dir, $list);
> }
>

Re: [PHP-DEV] new FTP function

[Paul Dragoonis]

On Fri, Jan 18, 2013 at 3:18 PM, KISE  wrote:

> $res  = ftp_nlist($this->conn_id, '-dF '. $dir);
>

This could be done in two lines.

function dir_exists($conn, $dir) {
$list  = ftp_nlist($conn, '-dF '. $dir);
return in_array($dir, $list);
}

Re: [PHP-DEV] new FTP function

[Paul Dragoonis]

I don't believe there's a feature of the FTP protocol to check if a
file/folder exists.

Can you please provide a PHP userland solution to this, so that a
corresponding C implementation could be added.

I believe the way to go about it is list the CWD contents and check if that
exists and is of type DIR. You must also make sure that if a file exists
with the name of the directory you want to check it has to handle that
properly, it can't simply return true or false. If false then that means
you could create it because it doesn't exist. If true it means you can CD
into it and put stuff there, which is also not true.

Thanks,
Paul.


On Fri, Jan 18, 2013 at 3:00 PM, Will Fitch  wrote:

>
> On Jan 18, 2013, at 9:53 AM, KISE  wrote:
>
> > Hi
> >
> > II would like to see "ftp_dir_exists()" function in PHP, right now its
> > kinda unreasonable to expect people to use hacks such as "is_dir()" and
> > having to re-authenticate just to check if the dir exists, I also dont
> > think its good idea to use "ftp_chdir()" just to check if the directory
> > exists, because its shows errors if the directory doesn't exists. i think
> > there should be a way to check if the directory exists without having to
> > resort to hackish ways, or having to authenticate again.
>
> There are procedures in place for this.  If you'd like to make a feature
> request, use bugs.php.net and submit the request with the FTP extension
> selected.  You can also use https://wiki.php.net/rfc if you really want
> to see/make the change as well.

Re: [PHP-DEV] 'Documentation'

[Paul Dragoonis]

On Tue, Jan 8, 2013 at 2:27 PM, Pierre Joye  wrote:

> On Tue, Jan 8, 2013 at 3:22 PM, Lester Caine  wrote:
>
> > Reflection/Annotations are just another way of 'documenting' classes -
> > aren't they?
>
> No.
>
> Annotations are used to affect behaviors, define services, etc. Check
> out the c# implementation for example.
>

Also, Doctrine uses them for defining relationships between entities.


>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Core liason for PHP FIG

[Paul Dragoonis]

On Sun, Dec 16, 2012 at 7:46 PM, Lester Caine  wrote:

> Pierre Joye wrote:
>
>> On Sun, Dec 16, 2012 at 3:26 PM, Lester Caine  wrote:
>> 
>>
>>> >
>>>
>> Once again this is totally off base. We are not discussing anything
>> proposed or adopted by the FIG group but how php.net can better
>> cooperate with this group. I urge you to stay on topic and move any
>> other topics to the right place.
>>
>
> Actually the question is perfectly valid ... why do we standardise on
> using TAB in the core code, but then use spaces in the php files?
> It would seem that FIG group standards have been adopted in some areas of
> PHP when the real standard is something different?
> I've just realised why I have been having problems with some area which
> USED to use the TAB standard but which have been switched to 'spaces'
> instead! So what IS the standard for file style in core code files? While
> ignoring white space on comparisons does work, it also results in problems
> when trying to commit changes to files which are using different white
> space standards.
>
> OK - scanning a few more files it would seem that spaces are an exception
> (fetch.php for example), and I've found the guideline calling for tab
> rather than spaces, but does that guideline apply transparently to .php
> files as well? Certainly .phpt files are consistently tabbed.
>
> It's not the only difference that FIG are pushing which is opposite to the
> style standards on the core code, so perhaps we should be lobbying them to
> come in line with the documented standards?


We done a survey on all the major projects and what their standards were
and went with the majority of what already existed. It doesn't matter what
we at FIG as long as it was consistent.


>
>
> --
> Lester Caine - G8HFL
> -
> Contact - 
> http://lsces.co.uk/wiki/?page=**contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - 
> http://rainbowdigitalmedia.co.**uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Required __construct call in SplFileObject

[Paul Dragoonis]

You could put it either inside introduction or just below it, in the 'info'
style, just to inform people they must call parent::__construct() upon
instantiation of their object in order to use this.


On Wed, Dec 5, 2012 at 2:46 PM, Paul Dragoonis  wrote:

> The way this class is designed, it needs to take the file name via the
> constructor as an "initiation point".
>
> if you try to call a method of this class without initiation occurring it
> will throw an exception.
>
> this is why you must instantiate the SplFileObject's __construct() method
> to start the initiation.
>
> Hope this helps.
> Paul.
>
> On Wed, Dec 5, 2012 at 2:38 PM, Christoph Rosse  wrote:
>
>> SplFileObject
>
>
>

Re: [PHP-DEV] Required __construct call in SplFileObject

[Paul Dragoonis]

The way this class is designed, it needs to take the file name via the
constructor as an "initiation point".

if you try to call a method of this class without initiation occurring it
will throw an exception.

this is why you must instantiate the SplFileObject's __construct() method
to start the initiation.

Hope this helps.
Paul.

On Wed, Dec 5, 2012 at 2:38 PM, Christoph Rosse  wrote:

> SplFileObject

Re: [PHP-DEV] SplDoublyLinkedList missing insertBefore/After

[Paul Dragoonis]

Hi Rafael,

I have worked on this code before and if the idea is accepted I'm happy to
add features to this class.

Let me know.
Thanks,
Paul.


On Thu, Nov 29, 2012 at 11:38 AM, Rafael Dohms wrote:

> I have just noticed that the current SPL inplementation of a
> DoublyLinkedList does not include methods to insert nodes into the middle
> of the list (insertBefore, insertAfter).
>
> After mentioning it I ran into a few people and other outbursts on the
> internet of more people who saw this and complained about it.
>
> I found a bug from 2009 (https://bugs.php.net/bug.php?id=48358) which
> mentions the case and has no Core response at all.
>
> I ask two questions:
>
> 1) Why was this bug never replied to, is there some reason these methods
> should not be implemented?
>
> 2) Is anyone willing to put up a patch for this? I imagine that if you are
> familiar with C and PHP source this is a quick implementation as its
> standard logic documented everywhere.
>
> I'm not familiar enough with the PHP source to do this myself, hence I'm
> asking for anyone willing to "champion" the patch.
>
> Thanks!
>
> --
> Rafael Dohms
> PHP Evangelist and Community Leader
> http://www.rafaeldohms.com.br
> http://www.amsterdamphp.nl
>

Re: [PHP-DEV] HTML escaped short echo tag

[Paul Dragoonis]

On Sun, Oct 21, 2012 at 2:35 PM, Charlie Somerville <
char...@charliesomerville.com> wrote:

> Hi internals,
>
> I'd like to propose a new short tag that echos with HTML escaping.
>
> XSS is still a significant problem for PHP apps, but it is less common in
> apps written with frameworks that provide automatic HTML escaping. However,
> many developers are still writing straight PHP without any framework and a
> feature like this in PHP itself could prove to be incredibly handy.
>
> One approach I sometimes use is defining a global function called h() which
> passes its argument through htmlspecialchars(). This works well, but it
> still adds a little bit of unwanted mental and typing overhead.
>
> Since escaping is desired the vast majority of the time , I'd like to see a
> short tag for outputting with escaping. This tag could become the de facto
> standard for echoing data, with  alternative.
>
> The new tag should be just as short and easy to type as  a fan of 
> Looking forward to hearing some feedback on this idea.
>

How do you propose we customise the escaping of such things, using
htmlentities() or htmlspecialchars? What about the ENT_QUOTES options, or
the charset to be used (UTF-8)?

If you standardise such functionality then you'll need to have a callback
executed.

I'm personally not a fan of your new syntax because it ass more  variations
to the way PHP is invoked and outputting information, but perhaps a generic
escape() function is in order. Maybe you're onto something, but I feel the
new php-invoking syntax isn't the way to go about it.

- Paul.


>
> Cheers,
>
> Charlie.
>

Re: [PHP-DEV] Generics proposal

[Paul Dragoonis]

Hi Nikita,

What you're asking for is useful in other languages, but it doesn't match
the style of PHP which is to be a quick and easy type-less scripting
language.

What you're proposing is clearly more suited to something like Java or C#,
but doesn't really belong here.

I'd also hate to see this anywhere near PHP.

Many thanks,
Paul.

On Sat, Oct 20, 2012 at 11:10 PM, Marco Pivetta  wrote:

> On 20 October 2012 23:09, Michael Stowe  wrote:
>
> > I see what you're trying to do but not a big fan of how it's being
> > implemented in the example given.
> >
> > - Mike
> >
> > Sent from my iPhone
> >
> > On Oct 20, 2012, at 4:02 PM, Rasmus Lerdorf  wrote:
> >
> > > On 10/20/2012 01:59 PM, Nikita wrote:
> > >> Hello, list. I want to propose generics. For those, who don't know
> what
> > it is, here's example: say we have a Comment class, that has a method
> > getBody. Also we have Collection class, that implements Traversable. Now,
> > if I want to validate all insertions into collection of comments, I would
> > need to create CommentCollection class, extend it from Collection, and
> > override all the methods that are dealing with adding new elements to
> > collection. Moreover, I can't have any hints from my IDE about type of
> > collection's elements, so if I'll have code like this:
> > >> foreach ($commentCollection as $comment) {
> > >>$comment->getBody();
> > >> }
> > >> There will be no way for IDE to know, of what type that object will
> be.
> > >>
> > >> But there's how I could solve my problem with generics:
> > >> class Collection implements Traversable
> > >> {
> > >>...
> > >>public function add(T $element){}
> > >> }
> > >> $collection = new Collection();
> > >>
> > >> $collection->add(new Comment());
> > >>
> > >> $collection->add("that will be error");
> > >>
> > >> Actually, that's, again, all about type hinting. If we went so far
> with
> > scalar type hinting, then generics would also be a good addition.
> > >>
> > >> So, what you think?
> > >
> > > Personally I would hate to see this anywhere near PHP.
> > >
> > > -Rasmus
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> Well, the example just shows what I've already got used to when working
> with Java.
> I like it and it would be of great help to me (especially in reducing the
> amount of code to be tested), but there's a lot more around that, like
> multiple generic types (new Map()) and how reflection would
> deal with it...
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

[Paul Dragoonis]

Good work Clint!

Performance is probably one of the things people will complain about
so it's good that your benchmark is proving that it's merely identical
to the old __get() approach.

What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?

I think this would be a valuable addition to PHP 5.5.

Cheers,
Paul.

On Mon, Oct 8, 2012 at 1:42 PM, Clint Priest  wrote:
> As an update, just ran some performance testing:
>
> master
> Cycles  Direct  
> Getter  __get
> v1.4 @ 10/8/20121m  .05s.21s  
>   .20s
>
> php 5.5.0-dev
> Cycles  Direct  
> Getter  __get
> v1.4 @ 10/8/20121m  .04sn/a   
>   .21s
>
> Performance of property accessors was important to me as I'm sure it will be 
> to many, on one million cycles of a simple getter, it's <.01s difference.  
> Depending on the run it is sometimes exactly the same performance.
>
>> -Original Message-
>> From: Clint Priest [mailto:cpri...@zerocue.com]
>> Sent: Monday, October 08, 2012 6:53 AM
>> To: internals@lists.php.net
>> Subject: [PHP-DEV] [RFC] Propety Accessors v1.1
>>
>> It's been a while since I posted any updates about this, a few individuals 
>> have been asking about it privately and wanting me to get it
>> out the door for PHP 5.5 release.  It's come a long way since the last time 
>> I posted about it.
>>
>> RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>>
>> Example Usage:
>>
>> class TimePeriod {
>> private $Seconds = 3600;
>>
>> public $Hours {
>> get { return $this->Seconds / 3600; }
>> set { $this->Seconds = $value; }
>> isset { return 
>> isset($this->Seconds); }
>> unset { 
>> unset($this->Seconds); }
>> }
>> }
>>
>> Changes / Updates
>>
>> * isset/unset accessor functions now implemented (object & static 
>> context, auto implementations, etc)
>>
>> * static accessor now fully functional
>>
>> * Reference functionality validated, tests written
>>
>> * All operators have been tested, tests written
>>
>> * read-only and write-only keywords: Added explanation of reasons 
>> for inclusion at the top of the appropriate RFC section
>>
>> * Tested for speed, approaches or meets __get() speed.
>>
>> Internally things have changed quite a bit
>>
>> * cleaned up and simplified
>>
>> * had been using 4 to 5 additional fn_flag slots, now down to two 
>> (READ_ONLY and WRITE_ONLY)
>>
>> * the automatic implementations now compiled internal php code, this 
>> greatly simplified that part of the code and future proofed
>> it.
>>
>> The code is available at the url below and is up to date with master, all 
>> tests pass.
>> https://github.com/cpriest/php-src
>>
>> I'd like to get this project wrapped up in time to make it to the 5.5 
>> release, only a few things remain to be completed/updated:
>>
>> * Check on reflection code written prior to major changes (tests 
>> still pass)
>>
>> * Add a few more reflection functions that were requested
>>
>> In total there are 79 tests for this new functionality, if there are any 
>> others that I have missed, please let me know.
>>
>> -Clint
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

[Paul Dragoonis]

On Wed, Sep 19, 2012 at 10:48 PM, Michael Shadle  wrote:
> On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady  
> wrote:
>> Hi Michael,
>>
>> See the link near the bottom of the RFC - even htmlspecialchars() has
>> unusual behaviour that's potentially insecure. I have no objections to
>> there being functions, of course, and the RFC makes that clear.
>> However, many programmers like me are obsessed are objects so having
>> an SPL class will obviously be near and dear to my design patterned
>> heart ;).
>
> After looking over the RFC finally, would it be that crazy to consider
> this an extension of the standard string functions?
>
> str_escape($string, $encoding, $flags) or probably better
> str_escape($string, $flags, $encoding) - since encoding could be

I'm also proposing escape_var(), just like filter_var(). If it's
str_escape() then that's still sane, it's consistent and that's all
that matters. :-)

- Paul.


> defaulted to UTF-8, but flags are really what differentiate the
> behavior...
>
> Then there is not a handful of functions but rather one that can be
> used as the abstraction point and the flags passed to it will change
> it's behavior, much like the filter functions.
>
> (I just see this falling under one solid defacto escape function
> standard, and it could live by itself as "escape" or something, or as
> it operates on strings, prefix it as such)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

[Paul Dragoonis]

@All,

I'd like to provide a real use case since i feel people have went off
on a tangent of their own. i.e: a list of blog posts.



escapeHtml($post->getTitle());?>



Please see the different needs for escaping generalised html output,
and the same but within an attribute.
This is an important problem that we need to try and solve, the
htmlspecialchars() stuff isn't good enough else we wouldn't need
custom preg_match() solution like in the proposed RFC.

I'm happy for this to be a SPL class or a function such as
escape_var() with options on it (similar to how filter_var() works
right now). Adding additional extensions in todays PHP eco-system is
actually not going to help us at all since only like 2% of people are
ever going to install it. It has to be in ./ext/standard/ or
./ext/spl/.

@Rasmus/Stas
Are you happy with us adding a new class or function to ./ext/spl/ or
./ext/standard/. This isn't one of these shiny "must have" features,
it's actually addressing a very important problem.

For PHP developers to benefit from the escaping functions provided by
zend/symfony they have to actually be using those frameworks and
that's really a small portion of PHP code out there in the wild. If we
can introduce the new escape_var() function or a new OO class (as per
the RFC) then it's going to be readily available in the future.

Many thanks,
Paul Dragoonis.

On Tue, Sep 18, 2012 at 9:22 PM, Ángel González  wrote:
> On 18/09/12 21:06, Pádraic Brady wrote:
>> Hi Ángel,
>>
>> The methods all refer to literal strings, values or digits. We can't
>> reasonably escape data while allowing valid markup for the current
>> context since that's a contradiction by its very nature. If you needed
>> to let user values drive CSS names, Javascript functions or variable
>> naming, or HTML markup, you need something completely different. For
>> example, HTML markup can be sanitised against a whitelist using
>> HTMLPurifier.
>>
>>> I'm fine with the concept, but I'm not sold on the interface.
>>> It should be really clear when each of them should be used.
>>>
>>> escapeHtml()
>>> Ok, this is going to be used to show content inside a html document.
>>>
>>> escapeHtmlAttr()
>>> Use when using unquoted html attributes, otherwise use html escaping.
>>> When was the last time I saw an unquotted attribute with user-provided 
>>> content?
>> Hopefully never since that's the ideal ;). However, HTML5 allows
>> unquoted attributes which is perfectly valid. We don't make the user's
>> choice on this but we could provide the relevant tool for escaping if
>> they are completely and irredeemably insane :P.
> Someone may be insane enough to try to destroy his planet, but "some insane
> soul might want it" is no reason to build such weapon. :)
>
> As it's a crazy thing to do, we shouldn't provide means to do it. If
> your parameter
> is not a hardcoded number, just quote it and use escapeX function on its
> content.
>
>
>>> I think it should be replaced by a quoteHtmlAttr() function which properly
>>> escapes the content and adds the quotes for you (or it might skip them
>>> if it determines it's not needed in this case).
>> The RFC focuses on escaping - not sanitising or reformatting.
> As an api client I just want to pass a parameter to the attribute.
>
> Doing
>  echo '';
> or
>  echo '';
>
> is equivalent, just a distinction on the function contract. But in the
> second case the function avoids the ambiguity on whether the attribute
> used double quotes, single ones or no quote at all, since it can choose
> the one it "prefers".
>
> The goal is to make easy to write secure code. I think the second way
> does it better. If we need to change the name of the rfc, so be it.
>
>
>>> escapeJs()
>>> Escape javascript... but inside 

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

[Paul Dragoonis]

On Tue, Sep 18, 2012 at 8:50 PM, Rasmus Lerdorf  wrote:
> On 09/18/2012 03:46 PM, Pádraic Brady wrote:
>> Bear in mind the RFC, in userland (and likely any PECL ext) implements
>> the ESAPI rules. They've been hacked on a lot over the years which is
>> why I made sure they were followed exactly. It's very unlikely that a
>> browser bug could scupper these unless they allowed in more unencoded
>> characters to be taken advantage of. There are benefits to reusing
>> pre-peer review rules.
>
> Sure, but you have potential for buffer overflows, regex
> backtrack/recursion issues and general programming errors when this
> moves to C. I guarantee there will be dozens of bugs in the first
> version no matter who writes it.

Hi Rasmus,

The existing implementations at symfony\zend are working pretty well.
They're using string manipulation and regex functions.
If we port it to C, can't we still use the exact same functions that
the PHP_FUNCTION() macros are calling to pretty much clone it.

Would this minimise the amount of change (if any) ?

- Paul

>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

[Paul Dragoonis]

Yep, I see where my suggestion for filter_var() isn't relevant.

I use symfony2's ecaper in the PPI\Templating\ component, and really like it.
Zend2's also seems pretty good.

It'd be nice to have this available as a ./ext/spl/ class or an
independent extension (really needed for 1 class?).

Cheers,
Paul.

On Tue, Sep 18, 2012 at 12:55 PM, Pádraic Brady  wrote:
> Hi Paul,
>
> The thing is that filter_var() is strongly associated with input
> sanitisation whereas Escaper addresses the other end of output. Also,
> escaping is inextricably linked to character encoding - we can't run
> into situations where the functions are specific to something like
> UTF-8 when the character encodings used in real life are far more
> diverse. Additionally, the RFC was an attempt to make escaping as
> explicit and restrictive as possible - give a user too many options,
> or too many dispersed units of functionality, and they'll invariably
> confuse and misinterpret themselves to Hell ;).
>
> Note: There is a stack of folk, for example, who use the ext/filter
> URL validator for HTTP validation - it also passes php:// and
> javascript:// URLs. If we're not explicit, they won't ever notice when
> they're doing it wrong.
>
> Paddy
>
> On Tue, Sep 18, 2012 at 12:34 PM, Paul Dragoonis  wrote:
>> On Tue, Sep 18, 2012 at 12:32 PM, Paul Dragoonis  wrote:
>>> Hi Paddy,
>>>
>>> Couldn't this just be a new option for the filter_var() function?
>>>
>>> $clean = filter_var($_POST['someVar'], XSS_CLEAN);
>>
>> I see from your RFC that you have a bunch of functions, I believe all
>> these could be options to filter_var, ie.: FILTER_ESCAPE_[URL, JS,
>> CSS, HTMLATTR].
>>
>> - Paul.
>>
>>>
>>> - Paul.
>>>
>>> On Tue, Sep 18, 2012 at 12:30 PM, Pádraic Brady  
>>> wrote:
>>>> Hi all,
>>>>
>>>> I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
>>>> The RFC is a proposal to implement a standardised means of escaping
>>>> data which is being output into XML/HTML.
>>>>
>>>> Cross-Site Scripting remains one of the most common vulnerabilities in
>>>> web applications and there is a continued lack of understanding
>>>> surrounding how to properly escape data. To try and offset this, I've
>>>> written articles, attempted to raise awareness and wrote the
>>>> Zend\Escaper class for Zend Framework. Symfony 2's Twig has since
>>>> adopted similar measures in line with its own focus on security.
>>>>
>>>> That's all. The RFC should be self-explanatory and feel free to pepper
>>>> me with questions. As the RFC notes, I'm obviously not a C programmer
>>>> so I'm reliant on finding a volunteer who's willing to take this one
>>>> under their wing (or into their basement - whichever works).
>>>>
>>>> https://wiki.php.net/rfc/escaper
>>>>
>>>> Best regards,
>>>> Paddy
>>>>
>>>> --
>>>> Pádraic Brady
>>>>
>>>> http://blog.astrumfutura.com
>>>> http://www.survivethedeepend.com
>>>> Zend Framework Community Review Team
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>
>
>
> --
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

[Paul Dragoonis]

On Tue, Sep 18, 2012 at 12:32 PM, Paul Dragoonis  wrote:
> Hi Paddy,
>
> Couldn't this just be a new option for the filter_var() function?
>
> $clean = filter_var($_POST['someVar'], XSS_CLEAN);

I see from your RFC that you have a bunch of functions, I believe all
these could be options to filter_var, ie.: FILTER_ESCAPE_[URL, JS,
CSS, HTMLATTR].

- Paul.

>
> - Paul.
>
> On Tue, Sep 18, 2012 at 12:30 PM, Pádraic Brady  
> wrote:
>> Hi all,
>>
>> I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
>> The RFC is a proposal to implement a standardised means of escaping
>> data which is being output into XML/HTML.
>>
>> Cross-Site Scripting remains one of the most common vulnerabilities in
>> web applications and there is a continued lack of understanding
>> surrounding how to properly escape data. To try and offset this, I've
>> written articles, attempted to raise awareness and wrote the
>> Zend\Escaper class for Zend Framework. Symfony 2's Twig has since
>> adopted similar measures in line with its own focus on security.
>>
>> That's all. The RFC should be self-explanatory and feel free to pepper
>> me with questions. As the RFC notes, I'm obviously not a C programmer
>> so I'm reliant on finding a volunteer who's willing to take this one
>> under their wing (or into their basement - whichever works).
>>
>> https://wiki.php.net/rfc/escaper
>>
>> Best regards,
>> Paddy
>>
>> --
>> Pádraic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>> Zend Framework Community Review Team
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

[Paul Dragoonis]

Hi Paddy,

Couldn't this just be a new option for the filter_var() function?

$clean = filter_var($_POST['someVar'], XSS_CLEAN);

- Paul.

On Tue, Sep 18, 2012 at 12:30 PM, Pádraic Brady  wrote:
> Hi all,
>
> I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
> The RFC is a proposal to implement a standardised means of escaping
> data which is being output into XML/HTML.
>
> Cross-Site Scripting remains one of the most common vulnerabilities in
> web applications and there is a continued lack of understanding
> surrounding how to properly escape data. To try and offset this, I've
> written articles, attempted to raise awareness and wrote the
> Zend\Escaper class for Zend Framework. Symfony 2's Twig has since
> adopted similar measures in line with its own focus on security.
>
> That's all. The RFC should be self-explanatory and feel free to pepper
> me with questions. As the RFC notes, I'm obviously not a C programmer
> so I'm reliant on finding a volunteer who's willing to take this one
> under their wing (or into their basement - whichever works).
>
> https://wiki.php.net/rfc/escaper
>
> Best regards,
> Paddy
>
> --
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] get_class_vars() returned information ORDER

[Paul Dragoonis]

Can we use reflection to inspect the properties in the order that they're
written, or the order that the parser found public/protected/private
keywords and properties.

Paul.

On Sun, Sep 9, 2012 at 1:10 PM, Sherif Ramadan wrote:

> On Sun, Sep 9, 2012 at 7:52 AM, Johannes Schlüter
>  wrote:
> >
> >
> > On Sep 9, 2012, at 10:22, Sherif Ramadan 
> wrote:
> >>> I'm curious whether the ORDER of the class properties returned by
> >>> get_class_vars(), is in some way guaranteed. I do not find mention of
> it
> >>> in the documentation.
> >>>
> >>
> >> The only real guarantee is that of how the class properties are stored
> >> in the hashtable. get_class_vars() is essentially just reading from a
> >> hashtable of class properties.
> >
> > There's no such guarantee. The fact that it is using a Hashtable which
> has an order is an implementation detail. This might change (even though a
> change is unlikely) The only promise of get_class_vars() is to return all.
> >
>
> Right, I should have said "there's no guarantee at all", but what I
> was trying to say was that this isn't really by guarantee of
> get_class_vars(). Just the fact that this particular implementation
> detail is unlikely to change is what makes it a convenient side
> effect.
>
> Sorry, that was poorly worded.
>
> > johannes
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Proposal: use SomeClass::staticMethod

[Paul Dragoonis]

Comments inline.

On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
 wrote:
> Hello Internals!
>
> I'm just on and off luker here but thought I'll throw in an idea for a
> feature I'd love to see in PHP: aliasing static methods.
>
> Syntax would look something like this:
>
>   use Namespaced\SomeClass::staticMethod;
>   use Some\Foo::bar as fooBar;
>
>   staticMethod(); // would call Namespaced\SomeClass::staticMethod()

Then you're confusing the reader, they think you're calling a
function, but you're actually calling a class method. Confusion++

>   fooBar(); // would call Some\Foo::bar()

What if a function called staticMethod() already exists, there'd be a
bunch of confusion on referring to the right one.

>
> This would make code more readable, by removing the the noise of
> repetition of class names. For use cases we can look at Java use cases
> for "import static".

When you find a function call, you'd have to scroll up to the top of
the page to see if it's actually a method alias. In this case being
explicit is a good thing, no scrolling, no confusion.

>
> Aliasing class constants like that would also be very nice.
>
> What does everyone think?
> Would it be possible in PHP?
>
> --
> Giedrius Dubinskas

Not that I don't welcome your suggestions, I encourage them, but for
this paritcular one I vote -1 on it.

Thanks.

>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions

[Paul Dragoonis]

On Tue, Jul 24, 2012 at 6:20 PM, Rasmus Lerdorf  wrote:
> On 07/24/2012 10:01 AM, Nikita Popov wrote:
>
>> Another, separate point against finally is that in PHP (unlike many
>> other languages) most (all?) built-in resources clean up after
>> themselves. So if you open a file you don't have to worry about
>> closing it again. It'll do that all by itself as soon as it goes out
>> of scope. The same applies to database handles, etc. As PHP uses
>> refcount based garbage collection the resource is actually cleaned up
>> right away, not just at the next GC run (which could be problematic if
>> you open up many files in a row).
>
> Which is the argument for why finally doesn't need to worry about the
> fatal-error case. Most resources are cleaned up on a fatal already,
> including your lock example, so it isn't an issue. finally is
> exception-level for intra-app cleanup, not for request shutdown cleanup.
> We already have shutdown functions for that case.

Exactly what I've been thinking.

If people are already doing die() in their code, they already don't
care about manually freeing up resources and will let php do its
shutdown process as normal.

I think existing concerns about php's resource freeing upon fatal
errors have been accidentally merged with the finally{} proposal,
which shouldn't be looking to change how things work, but provide an
additional block for further control.

I have had to workaround stuff in my PHP apps because of a lack of
finally{} block, and I hope it makes its way into the next iteration.

Thanks,
Paul.



>
> -Rasmus
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions

[Paul Dragoonis]

On Tue, Jul 24, 2012 at 12:20 PM, Laruence  wrote:
> Hi:
> As the previous threads disscussed,  I make a implemention.
>
> here is the RFC: https://wiki.php.net/rfc/finally
>
> any suggestions?
>
> thanks
>
> --
> Laruence  Xinchen Hui
> http://www.laruence.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Now this is the kind of stuff that's important to the upcoming
versions of PHP instead of talking about brace-less expressions.

We definitely need this, try {} catch {} finally {}.

Push this for discussion, in two weeks call a vote, I definitely see
this going through.

- Paul.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Make try/catch brackets optinal

[Paul Dragoonis]

On Thu, Jul 19, 2012 at 10:58 AM, Charlie Somerville
 wrote:
> On Thursday, 19 July 2012 at 7:49 PM, Paul Dragoonis wrote:
>
> Why is your try block only going to contain 1 line, and that's
> throwing an exception??
>
> try
> throw new Exception('foobar');
> catch(Exception $e)
>
> Because it's a contrived example. He's not trying to write real code, he's
> trying to demonstrate his point - and you totally missed that

You're right, I totally missed that point.

>
> Braces are a good thing, they give structure and stop people from
> mis-reading things and writing bugs, the same can be said for the if()
> situation.
>
> 1) Braces are good.
>
> This is subjective. There are some cases where it might improve code
> readability to drop the braces for a single-statement try/catch.
>
> There's certainly no technical barrier to doing this. I'm not familiar with
> PHP's parser, but I'd imagine there would be some kind of 'statement'
> non-terminal that would handle single statements as well as a braced group
> of statements.

Same sentiments as from Rafael, bracket-less is bug-prone.

>
> 2) Try with only one line in it to throw an exception doesn't seem
> like a realistic situation.
>
> There could be some utility to this. For example, as well as having post-fix
> if, unless, etc., Ruby also has a post-fix 'rescue'. Here's a silly example
> of its use:
>
> some_var = foo.bar rescue "oops"
>
> If 'foo.bar' threw an exception, some_var would contain "oops" instead.
>
> I think PHP could benefit from having a single statement try form. I often
> turn to PHP for quick and dirty scripts when I need to do something with
> little fuss. I think having try/catch support brace-less single statements
> would help increase consistency in PHP's syntax, as well as be useful in
> certain situations.
>
> On Thursday, 19 July 2012 at 7:49 PM, Paul Dragoonis wrote:
>
>
> -1 from me, sorry Hoa.
>
> On Thu, Jul 19, 2012 at 10:44 AM, Ivan Enderlin @ Hoa
>  wrote:
>
> Hi internals,
>
> As you certainly know, brackets defining blocks in PHP are optional if
> blocks contain a single instruction. Thus:
>
> if($condition) {
> echo 'foobar';
> }
>
> is strictly equivalent to:
>
> if($condition)
> echo 'foobar';
>
> But this syntactic sugar is not applied uniformly to all PHP language
> constructions. I have the try/catch couple in mind.
> First, I would like to know why it is not possible to write:
>
> try
> throw new Exception('foobar');
> catch(Exception $e)
> var_dump($e->getMessage());
>
> as a strict equivalence of:
>
> try {
> throw new Exception('foobar');
> }
> catch(Exception $e) {
> var_dump($e->getMessage());
> }
>
> Second, if it is possible, could we plan to have this “feature” (uniformity
> actually) in PHP6 (or maybe before)?
>
> Best regards.
>
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa.42/ or http://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://disc.univ-fcomte.fr/ and http://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Make try/catch brackets optinal

[Paul Dragoonis]

Why is your try block only going to contain 1 line, and that's
throwing an exception??

try
throw new Exception('foobar');
catch(Exception $e)


Braces are a good thing, they give structure and stop people from
mis-reading things and writing bugs, the same can be said for the if()
situation.

1) Braces are good.
2) Try with only one line in it to throw an exception doesn't seem
like a realistic situation.

-1 from me, sorry Hoa.

On Thu, Jul 19, 2012 at 10:44 AM, Ivan Enderlin @ Hoa
 wrote:
> Hi internals,
>
> As you certainly know, brackets defining blocks in PHP are optional if
> blocks contain a single instruction. Thus:
>
> if($condition) {
> echo 'foobar';
> }
>
> is strictly equivalent to:
>
> if($condition)
> echo 'foobar';
>
> But this syntactic sugar is not applied uniformly to all PHP language
> constructions. I have the try/catch couple in mind.
> First, I would like to know why it is not possible to write:
>
> try
> throw new Exception('foobar');
> catch(Exception $e)
> var_dump($e->getMessage());
>
> as a strict equivalence of:
>
> try {
> throw new Exception('foobar');
> }
> catch(Exception $e) {
> var_dump($e->getMessage());
> }
>
> Second, if it is possible, could we plan to have this “feature” (uniformity
> actually) in PHP6 (or maybe before)?
>
> Best regards.
>
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa.42/ or http://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://disc.univ-fcomte.fr/ and http://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New String Function: str_replace_limit

[Paul Dragoonis]

On Mon, Jul 16, 2012 at 12:23 PM, Florian Anderiasch
 wrote:
> On 07/16/2012 10:29 AM, Paul Dragoonis wrote:
>> Thanks for the comments guys, I like your idea about skipping the
>> by-ref count parameter.
>>
>> If the 'default' keyword were to be added in, then you could skip the
>> 4th parameter and add your 5th 'limit' option.
>>
>> $str = str_replace($search, $replace, $subject, default, 5);
>>
>> Does anyone have any objections on this implementation approach?
>> (obviously we'd have to wait for the default param skipping to be
>> implemented, I'm not sure on the implementation status of that
>> feature)
>
> I'm not seeing what's the problem with it being a by-ref variable, as
> you've mentioned it twice now. Are you bothered by an additional
> variable being set in memory when skipping (i.e. not using it)? Or am I
> reading more into it than you tried to say? :)

I believe you were reading more into it.

I mention by-ref so it's easy to know if i'm talking about the
existing or new proposed param.

I'm not bothered by the by-ref param being skipped over to get to the
5th one, it's a hit I'm willing to take to achieve necessary
functionality on str_replace().

If nobody has any further concerns I'll go ahead and create this new
parameter and provide a PR on github accordingly.

Paul Dragoonis.

>
> Greetings,
> Florian

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New String Function: str_replace_limit

[Paul Dragoonis]

Thanks for the comments guys, I like your idea about skipping the
by-ref count parameter.

If the 'default' keyword were to be added in, then you could skip the
4th parameter and add your 5th 'limit' option.

$str = str_replace($search, $replace, $subject, default, 5);

Does anyone have any objections on this implementation approach?
(obviously we'd have to wait for the default param skipping to be
implemented, I'm not sure on the implementation status of that
feature)

Thanks.
Paul Dragoonis.

On Mon, Jul 16, 2012 at 9:08 AM, Kingsquare.nl - Robin Speekenbrink
 wrote:
> Hi all,
>
> I'm a strict follower of this list and havent posted (as of yet) due to the
> fact that i'd like to be in the loop, but am not a C developer... :)
>
> But on this discussion i'd like to give my 2c: As a PHP developer i'd regret
> to see yet another function added to the language instead of adding a new
> parameter. (this it does the same thing just limited) Also with the other
> discussion on being able to skip default parameters (using the keyword
> 'default') this shouldnt be a problem should it?
>
> Thanks, i'll butt out now :D
>
> Op maandag 16 juli 2012 10:05:02, Gustavo Lopes schreef:
>
>> On Sun, 15 Jul 2012 20:59:10 +0100, Paul Dragoonis wrote:
>>>
>>> The 4th param to str_replace is a by-ref param, so you can't just skip
>>> over it, can you ?
>>>
>>
>> I don't think so, but we could make it so that you could by using
>> optional passing by reference.
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New String Function: str_replace_limit

[Paul Dragoonis]

The 4th param to str_replace is a by-ref param, so you can't just skip
over it, can you ?

On Sun, Jul 15, 2012 at 8:54 PM, Felipe Pena  wrote:
> Hi,
>
> 2012/7/15 Paul Dragoonis :
>> Hey,
>>
>> I'm proposing to add a new function str_replace_limit, this will be
>> identical to str_replace() with one key difference, you can specify
>> how many times you want the replace to occur.
>>
>> Currently this isn't possible with any functions in the
>> /ext/standard/string.c stack, the only easy workaround is using
>> preg_replace() which requires of course the pcre library and regex
>> patterns.
>>
>> I would have added this as a 4th param to str_replace(), but it
>> already has a 4th by-ref param to tell you how many times it done the
>> replacement.
>>
>> mixed str_replace_limit ( mixed $search , mixed $replace , mixed
>> $subject [, int $limit ] )
>>
>> Thoughts?
>>
>
> Surely a 5th param is preferred.
>
> --
> Regards,
> Felipe Pena

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] New String Function: str_replace_limit

[Paul Dragoonis]

Hey,

I'm proposing to add a new function str_replace_limit, this will be
identical to str_replace() with one key difference, you can specify
how many times you want the replace to occur.

Currently this isn't possible with any functions in the
/ext/standard/string.c stack, the only easy workaround is using
preg_replace() which requires of course the pcre library and regex
patterns.

I would have added this as a 4th param to str_replace(), but it
already has a 4th by-ref param to tell you how many times it done the
replacement.

mixed str_replace_limit ( mixed $search , mixed $replace , mixed
$subject [, int $limit ] )

Thoughts?

Paul Dragoonis.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: array_last_key() function

[Paul Dragoonis]

(forgot to CC internals on the previous email)

On Sat, Jul 14, 2012 at 4:42 PM, John LeSueur  wrote:
> Readability is solved by creating a userland function:
>
> function array_last_key(&$array)
> {
> return key(array_slice($array, -1,1,true));
> }

Another userland function, with a by-ref parameter. Again more
unnecessary complexity, solved by our new friend array_last_key.

I hope this gets put into a branch soon, I'll happily +1 vote it.

- Paul.

>
> $lastkey = array_last_key($array);
>
> Now, it may still be quicker, or use less memory(temporarily) if it were a
> core function, but I'd like to see numbers before making a decision. I would
> still want to see a significant advantage before it is added to core.
>
>
> On Sat, Jul 14, 2012 at 9:33 AM, Paul Dragoonis  wrote:
>>
>> $lastKey = key(array_slice($array,-1,1,true));
>> vs
>> $lastKey = array_last_key($array);
>>
>> The latter will be quicker, use less memory and easier to read/maintain.
>>
>> - Paul.
>>
>> On Sat, Jul 14, 2012 at 4:28 PM, John LeSueur 
>> wrote:
>> >
>> >
>> > On Sat, Jul 14, 2012 at 4:34 AM, Paul Dragoonis 
>> > wrote:
>> >>
>> >> On Sat, Jul 14, 2012 at 3:04 AM, Anthony Ferrara 
>> >> wrote:
>> >> > Stas,
>> >> >
>> >> >> I like this idea. array_first_key would be nice too
>> >> >>
>> >> >> I am probably missing something, but what those would allow to do
>> >> >> that
>> >> >> rewind/end+key() doesn't do?
>> >> >>
>> >> >
>> >> > The big thing that it does that end()+key() doesn't do is really what
>> >> > it
>> >> > doesn't do (update the internal pointer).
>> >> >
>> >> > end() modifies the array pointer. So if you try this in user-land:
>> >> >
>> >> > function array_last_key(array $array) {
>> >> > end($array);
>> >> > return key($array);
>> >> > }
>> >> >
>> >> > It will always force a full copy of the array (at least the hash
>> >> > table).
>> >> > Implementing this as a core function however would eliminate that one
>> >> > side-effect...
>> >>
>> >> and it beats doing $var = null; if(isset($array[0])) { $var =
>> >> $array[0]; }
>> >>
>> > Not sure that does the trick(you're pulling values, not keys, and
>> > assuming
>> > 0-based array), but...
>> >
>> > What about reset(array_keys($array)); or end(array_keys($array)); which
>> > only
>> > makes copies of the keys?
>> > or even better key(array_slice($array, 0, 1, true)); or
>> > key(array_slice($array,-1,1,true)); which makes a copy of one element of
>> > the
>> > array?
>> >
>> > I'm of the opinion that we mostly have enough array_* functions, and new
>> > ones have to provide a significant advantage to be accepted. If these
>> > functions are significantly faster than the alternatives, then perhaps
>> > they
>> > have merit, but they seem like convenience functions, rather than
>> > fundamentals.
>> >
>> > John
>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: array_last_key() function

[Paul Dragoonis]

On Sat, Jul 14, 2012 at 3:04 AM, Anthony Ferrara  wrote:
> Stas,
>
>> I like this idea. array_first_key would be nice too
>>
>> I am probably missing something, but what those would allow to do that
>> rewind/end+key() doesn't do?
>>
>
> The big thing that it does that end()+key() doesn't do is really what it
> doesn't do (update the internal pointer).
>
> end() modifies the array pointer. So if you try this in user-land:
>
> function array_last_key(array $array) {
> end($array);
> return key($array);
> }
>
> It will always force a full copy of the array (at least the hash table).
> Implementing this as a core function however would eliminate that one
> side-effect...

and it beats doing $var = null; if(isset($array[0])) { $var = $array[0]; }

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Hash_pbkdf2

[Paul Dragoonis]

I see no coding examples, just a function declaration.

On Mon, Jul 2, 2012 at 5:34 PM, Anthony Ferrara  wrote:

> Hello all,
>
> I've opened voting for the hash_pbkdf2 RFC adding hash_pbkdf2() to master:
>
> https://wiki.php.net/rfc/hash_pbkdf2#vote
>
> Thanks,
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning

[Paul Dragoonis]

My input is that we should be focusing on features that PHP lacks, or
fixing bugs rather than adding more sugar syntax just for the sake of
adding it.

On Fri, Jun 29, 2012 at 7:47 PM, Pierrick Charron wrote:

> No problem when you'll come in Montreal ! If you need any help don't
> hesitate.
>
> Pierrick
>
> On 29 June 2012 14:27, Amaury Bouchard  wrote:
>
> > Yes, guys. I totally understand your point. As I said, I had this idea in
> > a dreamed context (good or bad dream? I don't know).
> > But still, I think it's intellectually interesting, even if it's not a
> > good concept for PHP.  :-)
> >
> > Pierrick, I owe you a beer  ;-)
> > Le 29 juin 2012 19:06, "Pierrick Charron"  a
> écrit :
> >
>

Re: [PHP-DEV] [DRAFT] RFC - array_column() function

[Paul Dragoonis]

What about array_extract ?

On Mon, Jun 25, 2012 at 9:31 PM, Aaron Holmes  wrote:

> For what my .02 is worth, I imagine "plucking" an item out of an array
> would not occur to a user-land developer as the proper nomenclature for
> extracting all the values from an array with the given key. At worst, this
> means many developers simply won't learn about the function and continue to
> implement it in user-land.
>
> When array_column was offered as the name, I immediately knew what the
> purpose was, before checking the RFC.
>
>
> On 6/25/2012 12:22 PM, Ben Ramsey wrote:
>
>> On 6/25/12 9:44 AM, Matthew Weier O'Phinney wrote:
>>
>>> On 2012-06-23, Stas Malyshev  wrote:
>>>
 I'm open to changing or aliasing the name to array_pluck(), if others
> are in agreement.
>

 I wouldn't know what "pluck" means here. "Column" is a clear word with
 established meaning. Let's not get too whimsical here.

>>>
>>> Nothing whimsical about it at all, Stas. The definition is:
>>>
>>> Take hold of (something) and quickly remove it from its place; pick
>>>
>>> and synonyms include "pull" and "gather".
>>>
>>> As Ralph noted, "column" is overloaded, as it has connotations dealing
>>> with databases as well as tables, and arrays often represent neither.
>>>
>>>
>> I agree with Tom and Ralph that we should look at what others are doing
>> and pick a similar name. After searching on "pluck," though, I'm getting
>> mixed results on how pluck is used:
>>
>> In Rails, it looks like pluck is used for the purpose that I've created
>> array_column, but it's used with ActiveRecord as a way to pull a column of
>> results from the database (much like PDOStatement::fetchColumn). See here:
>>
>> https://github.com/rails/**rails/commit/**a382d60f6abc94b6a965525872f858*
>> *e48abc00de
>>
>> However, in Prototype.js and Underscore.js, pluck seems behave more like
>> array_map() in PHP:
>>
>> http://api.prototypejs.org/**language/Enumerable/prototype/**pluck/
>> http://documentcloud.github.**com/underscore/#pluck
>>
>> Nevertheless, it would technically have the same effect as the "column"
>> functionality, since calling that method/property in Javascript simply
>> returns the value of the property or result of the method call.
>>
>> Also, the Python community has recently discussed adding pluck for lists:
>>
>> https://groups.google.com/**forum/?fromgroups#!topic/**
>> python-ideas/p9qtUzg9zsk
>>
>> It looks like they already have some functionality that implements
>> similar behavior, though:
>>
>> >>> stooges=[{'name': 'moe', 'age': 40}, {'name': 'larry', 'age': 50},
>> {'name': 'curly', 'age': 60}]
>> >>> names=[guy['name'] for guy in stooges]
>> >>> print names
>> ['moe', 'larry', 'curly']
>>
>> array_column/pluck in PHP would do the same:
>> $names = array_column($stooges, 'name');
>>
>> If other languages/frameworks/libraries are using pluck to mean exactly
>> what this implementation means, then I agree with changing the name to
>> array_pluck, but if "pluck" also carries meaning similar to array_map, then
>> I don't want to confuse folks.
>>
>> -Ben
>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [DRAFT] RFC - array_column() function

[Paul Dragoonis]

On Thu, Jun 21, 2012 at 8:27 PM, Ben Ramsey  wrote:
> Hi all,
>
> I've written a draft version of an RFC for pull request 56 (
> https://github.com/php/php-src/pull/56 ), to add array_column() to the core.
> Please take a look and provide feedback so that I can improve the
> patch/proposal.
>
> https://wiki.php.net/rfc/array_column

I like your proposal and code examples on the RFC, this function is
useful and would save a foreach() to get the specified keys/indexes
out of the array.

- Paul.

>
> Thanks,
> Ben
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php