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 <bobw...@hotmail.com> 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 <dragoo...@gmail.com>:
> >
> > 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 <xinche...@zend.com> wrote:
> >
> >> Hey:
> >>
> >>
> >>
> >> On Wed, Nov 4, 2015 at 3:58 AM, Dmitry Stogov <dmi...@zend.com> 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 ocram...@gmail.com 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 stelian.mocan...@gmail.com
 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 ircmax...@gmail.com
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 ircmax...@gmail.com
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 Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski anatol@belski.net
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] [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 lei...@gmail.com wrote:

 On 10 February 2015 at 23:29, Paul Dragoonis dragoo...@gmail.com 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] 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 dmi...@zend.com 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 smalys...@gmail.com 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 nikita@gmail.com wrote:

 On Sat, Jan 17, 2015 at 8:40 PM, Nikita Popov nikita@gmail.com
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 smalys...@gmail.com
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 kont...@beberlei.de wrote:

 On Wed, Jan 7, 2015 at 8:33 PM, Benjamin Eberlei kont...@beberlei.de
 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 ben.co...@zeyos.com 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 bu...@php.net 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 poll...@php.net wrote:

 On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye pierre@gmail.com 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 le...@php.net 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 a...@ajf.me wrote:


  On 20 Dec 2014, at 15:50, Andrea Faulds a...@ajf.me wrote:
 
 
  On 14 Dec 2014, at 18:35, Andrea Faulds a...@ajf.me 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 nf.laupre...@yahoo.fr 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 anatol@belski.net
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 dmi...@zend.com 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 anatol@belski.net
 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:18, Nikita Popov nikita@gmail.com wrote:

 On Mon, Nov 24, 2014 at 1:10 AM, Andrea Faulds a...@ajf.me 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] Zend Engine 3

[Paul Dragoonis]

On 24 Nov 2014 12:32, Paul Dragoonis dragoo...@gmail.com wrote:


 On 24 Nov 2014 12:18, Nikita Popov nikita@gmail.com wrote:
 
  On Mon, Nov 24, 2014 at 1:10 AM, Andrea Faulds a...@ajf.me 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] New Standardized HTTP Interface

[Paul Dragoonis]

On 30 Oct 2014 19:03, Sherif Ramadan theanomaly...@gmail.com 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]

Hi person hiding behind a project,

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]

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

On Tue, Sep 23, 2014 at 12:17 PM, Park Framework park.framew...@gmail.com
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 dragoo...@gmail.com:
  Hi person hiding behind a project,
 
  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]

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 insert best overall serializer lib
here by default in PHP7 ?


On Tue, Sep 23, 2014 at 12:57 PM, Pierre Joye pierre@gmail.com wrote:

 http://pecl.php.net/package/msgpack

 On Tue, Sep 23, 2014 at 1:34 PM, Leigh lei...@gmail.com wrote:
  On 23 September 2014 12:22, Paul Dragoonis dragoo...@gmail.com 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] 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 tjerk.meest...@gmail.com 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 le...@php.net wrote:

 On Wed, Aug 20, 2014 at 7:30 AM, Paul Dragoonis dragoo...@gmail.com
 wrote:
  On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans a...@zend.com 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 Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans a...@zend.com 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 nikita@gmail.com 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] Abstract Syntax Tree

[Paul Dragoonis]

On Wed, Aug 20, 2014 at 2:57 PM, Nikita Popov nikita@gmail.com wrote:

 On Wed, Aug 20, 2014 at 3:30 PM, Paul Dragoonis dragoo...@gmail.com
 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] Mutliple defaults in switch statements

[Paul Dragoonis]

On 12 Aug 2014 22:36, Sara Golemon poll...@php.net wrote:

 On Tue, Aug 12, 2014 at 10:08 AM, Andrea Faulds a...@ajf.me wrote:
  On 12 Aug 2014, at 17:53, Sara Golemon poll...@php.net 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 krak...@php.net wrote:

 On 10/07/2013 11:20 AM, Peter Cowburn wrote:

 On 7 October 2013 11:13, Joe Watkins krak...@php.net 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#votinghttps://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 sebast...@php.netwrote:

 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 jpa...@php.net 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 ircmax...@gmail.comwrote:

 Marcello,


 On Tue, Feb 19, 2013 at 7:57 AM, Marcello Duarte mdua...@inviqa.com
 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 d...@damz.org wrote:

 On Fri, Feb 15, 2013 at 9:54 AM, Pierre Joye pierre@gmail.com 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 patrickalla...@php.netwrote:

 2013/2/14 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net:
  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]

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 hanskren...@yahoo.de wrote:



 - Ursprüngliche Message -

  Von: Stas Malyshev smalys...@sugarcrm.com
  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] 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 tyr...@gmail.com wrote:

 2013.01.30. 19:16, Stas Malyshev smalys...@sugarcrm.com 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] 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 willfi...@php.net wrote:


 On Jan 18, 2013, at 9:53 AM, KISE wowk...@gmail.com 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] new FTP function

[Paul Dragoonis]

On Fri, Jan 18, 2013 at 3:18 PM, KISE wowk...@gmail.com 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 dragoo...@gmail.com wrote:


 On Fri, Jan 18, 2013 at 3:18 PM, KISE wowk...@gmail.com 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]

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 dragoo...@gmail.com 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 dragoo...@gmail.comwrote:


 On Fri, Jan 18, 2013 at 3:18 PM, KISE wowk...@gmail.com 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] 'Documentation'

[Paul Dragoonis]

On Tue, Jan 8, 2013 at 2:27 PM, Pierre Joye pierre@gmail.com wrote:

 On Tue, Jan 8, 2013 at 3:22 PM, Lester Caine les...@lsces.co.uk 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 les...@lsces.co.uk wrote:

 Pierre Joye wrote:

 On Sun, Dec 16, 2012 at 3:26 PM, Lester Caineles...@lsces.co.uk  wrote:
 snip

 

 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=**contacthttp://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.**ukhttp://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]

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 c...@okto.tv wrote:

 SplFileObject

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 dragoo...@gmail.com 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 c...@okto.tv 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 lis...@rafaeldohms.com.brwrote:

 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] 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 ocram...@gmail.com wrote:

 On 20 October 2012 23:09, Michael Stowe mikegst...@gmail.com 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 ras...@lerdorf.com 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 CollectionT implements Traversable
   {
  ...
  public function add(T $element){}
   }
   $collection = new CollectionComment();
  
   $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 MapComment, User()) and how reflection would
 deal with it...

 Marco Pivetta

 http://twitter.com/Ocramius

 http://ocramius.github.com/

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 ?= being seen as the more dangerous
 alternative.

 The new tag should be just as short and easy to type as ?=. Personally I'm
 a fan of ?- or perhaps ?~.

 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] [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 cpri...@zerocue.com 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; }
 issethttp://www.php.net/isset { return 
 issethttp://www.php.net/isset($this-Seconds); }
 unsethttp://www.php.net/unset { 
 unsethttp://www.php.net/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 mike...@gmail.com wrote:
 On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady padraic.br...@gmail.com 
 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]

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 padraic.br...@gmail.com 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]

On Tue, Sep 18, 2012 at 12:32 PM, Paul Dragoonis dragoo...@gmail.com 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 padraic.br...@gmail.com 
 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]

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 padraic.br...@gmail.com 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 dragoo...@gmail.com wrote:
 On Tue, Sep 18, 2012 at 12:32 PM, Paul Dragoonis dragoo...@gmail.com 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 padraic.br...@gmail.com 
 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 8:50 PM, Rasmus Lerdorf ras...@lerdorf.com 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]

@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.

?php foreach($posts as $post): ?
pa href=/blog/view/?=$post-getID();?
title=?=$escaper-escapeHtmlAttr($post-getTitle());?
?=$escaper-escapeHtml($post-getTitle());?
/a/p
?php endforeach; ?

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 keis...@gmail.com 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 'b style=' . escaper-escapeHtml(font-weight: normal) . '';
 or
  echo 'b style=' . escaper-quoteHtmlAttrib(font-weight: normal) . '';

 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 script tags, I guess? So it's not to
 be used
 for dynamically generated javascript. Not so clear.
 Javascript literal strings (as defined by the standard).

 Ok. We have the ' or  problem again, though.


 escapeCss()
 I'm not even sure in which cases would this be needed. Standalone CSS,
 inside
 a style tag, as style= attribute?
 CSS values like a font size or background color. If user data is
 allowed to alter names or any other CSS markup, you would need
 sanitisation rather than escaping.
 I was thinking in things like dynamic class names (I had no idea why you
 could
 want it, though :). It may be better named escapeCssValue()


 escapeUrl()
 It is included primarily for consistency. When do I need to use
 escapeUrl and
 when escapeHtml? What if it's an url inside a css tag inside a html
 document?
 Basically any URL inside any attribute. It encodes part of a URL - the
 overall URL would still need to be validated separately.

 If it encodes *part of a url*, it's not for *any url*.

 By any URL inside any attribute, I'd expect an usage

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 theanomaly...@gmail.comwrote:

 On Sun, Sep 9, 2012 at 7:52 AM, Johannes Schlüter
 johan...@schlueters.de wrote:
 
 
  On Sep 9, 2012, at 10:22, Sherif Ramadan theanomaly...@gmail.com
 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
d.giedr...@gmail.com 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 12:20 PM, Laruence larue...@php.net 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] [RFC] Supports 'finally' keyword for PHP exceptions

[Paul Dragoonis]

On Tue, Jul 24, 2012 at 6:20 PM, Rasmus Lerdorf ras...@lerdorf.com 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] 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
ivan.ender...@hoa-project.net 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] Make try/catch brackets optinal

[Paul Dragoonis]

On Thu, Jul 19, 2012 at 10:58 AM, Charlie Somerville
char...@charliesomerville.com 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
 ivan.ender...@hoa-project.net 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] 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
ro...@kingsquare.nl 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]

On Mon, Jul 16, 2012 at 12:23 PM, Florian Anderiasch
flor...@anderiasch.de 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

[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] 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 felipe...@gmail.com wrote:
 Hi,

 2012/7/15 Paul Dragoonis dragoo...@gmail.com:
 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

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

[Paul Dragoonis]

On Sat, Jul 14, 2012 at 3:04 AM, Anthony Ferrara ircmax...@gmail.com 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] 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 john.lesu...@gmail.com 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 dragoo...@gmail.com 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 john.lesu...@gmail.com
 wrote:
 
 
  On Sat, Jul 14, 2012 at 4:34 AM, Paul Dragoonis dragoo...@gmail.com
  wrote:
 
  On Sat, Jul 14, 2012 at 3:04 AM, Anthony Ferrara ircmax...@gmail.com
  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] [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 ircmax...@gmail.com 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 pierr...@webstart.frwrote:

 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 ama...@amaury.net 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 pierr...@webstart.fr 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 aa...@aaronholmes.net 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 smalys...@sugarcrm.com 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*
 *e48abc00dehttps://github.com/rails/rails/commit/a382d60f6abc94b6a965525872f858e48abc00de

 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://api.prototypejs.org/language/Enumerable/prototype/pluck/
 http://documentcloud.github.**com/underscore/#pluckhttp://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/p9qtUzg9zskhttps://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 ram...@php.net 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

[PHP-DEV] Subdomain Set Up

[Paul Dragoonis]

Hi Internals,

I attempted to get (and failed) some attention on my request that I
posted to php-webmaster mailing list, so I'm escalating it here:

http://news.php.net/php.webmaster/13696

Thanks,
Paul Dragoonis.

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

Re: [PHP-DEV] Subdomain Set Up

[Paul Dragoonis]

Okay,

Thanks for the reply.

On Sat, Jun 16, 2012 at 1:34 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
 On Sat, 16 Jun 2012 14:17:04 +0200, Paul Dragoonis dragoo...@gmail.com
 wrote:

 I attempted to get (and failed) some attention on my request that I
 posted to php-webmaster mailing list, so I'm escalating it here:

 http://news.php.net/php.webmaster/13696


 I agree that this request should not be granted. I don't see why we should
 be in the business of, among other things, deciding whether code should be
 indented or otherwise formatted.

 --
 Gustavo Lopes

 --
 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] [DISCUSSION] array_part()

[Paul Dragoonis]

Can you please add some code examples on the RFC, that get outputted as
pre tags.

Ideally demonstrating var_dump() output to inspect the return value of your
new function to get a clear indication of the input, and resulting output.

- Paul.

On Mon, May 14, 2012 at 11:21 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:

 Hi

 I have a proposal to add a new function to ext/standard: array_part():

 https://wiki.php.net/rfc/**array_parthttps://wiki.php.net/rfc/array_part

 Comments would be very welcome, especially the constructive kind.

 Please keep this on topic. In particular, avoid proposing new syntax as
 I'm not interested in that. You can of course create your own RFC for that
 purpose.

 --
 Gustavo Lopes

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

Re: [PHP-DEV] [RFC] [DISCUSSION] array_part()

[Paul Dragoonis]

Hey,

Am i correct in assuming this is basically substr() for arrays.

On Mon, May 14, 2012 at 11:29 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:

 On Mon, 14 May 2012 12:26:11 +0200, Paul Dragoonis dragoo...@gmail.com
 wrote:

  Can you please add some code examples on the RFC, that get outputted as
 pre tags.

 Ideally demonstrating var_dump() output to inspect the return value of
 your
 new function to get a clear indication of the input, and resulting output.


 The examples were linked from the RFC page. I've made the link more
 obvious. In any case, here is the URL:

 https://gist.github.com/**2660601#file_test.phphttps://gist.github.com/2660601#file_test.php


 --
 Gustavo Lopes