Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

[Lars Strojny]

Hi Sara, hi Frederik,

 

Thinking more about this I came to change my vote (and for that reason I’ll 
take back the suggestion to include it into 7.2):

 
The array API is the better API and allows for healthier future growth so we 
should pursue that option 
There is a (very ugly) workaround to set a same site policy by misusing the 
“session.cookie_path” or “session.cookie_domain” setting (e.g. set it to “/; 
SameSite=Strict”, you are welcome, Internet).
 

cu,

Lars

 

 

On 28.08.17, 18:20, "Sara Golemon"  wrote:

 

On Mon, Aug 28, 2017 at 12:10 PM, Frederik Bosch | Genkgo  
wrote:

Little misunderstanding then. I agree we can better have this PHP 7.3 and take 
some time for it. Current votes also suggest that we should go for the array 
argument implementation. Since there is only a PR for the extra argument 
implementation, it will also take time to have the PR for the array argument 
implementation ready. Taken that into account, we should not want this in 7.2.

Indeed, yes. Assuming the votes continue on this sharp lean towards the array 
option, we should just forget all notions of trying to sneak this into 7.2.

 

Direct calls in 7.2 and earlier can easily fall back on calling 
header('Set-Cookie: ...'); manually, while sessions support is slightly more 
complex, but still doable from userspace.  I expect if need is deemed high for 
this, a drop-in composer package can do 90% of the work automatically.

-Sara 

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

[Lars Strojny]

Hi Sara, hi Frederik,

Sounds good! Let's vote in getting it in first and then we can have a 2nd RFC 
(and vote) if it should land in 7.2

cu,
Lars

Sent from my electronic toy

> On 26. Aug 2017, at 17:34, Frederik Bosch  wrote:
> 
> Hi Sara,
> 
> Thanks for clearing this. I have no intension to have it merged in 7.2 so I 
> updated the RFC to specifically mention it is for 7.3. If other people want 
> to have it in 7.2, they can start a new RFC to make that happen.
> 
> Best,
> Frederik
> 
> 
> 
>> On 26-08-17 01:10, Sara Golemon wrote:
>>> On Fri, Aug 25, 2017 at 6:18 PM, Dan Ackroyd  wrote:
 On 25 August 2017 at 22:19, Frederik Bosch  wrote:
 LS,
 
 Just now, I opened the RFC on implementing same site cookies in PHP,
 https://wiki.php.net/rfc/same-site-cookie, for voting.
>>> Please be explicit:
>>> 
 Proposed PHP Version(s)
 next PHP 7.x
>>> 
>>> It's really late in the day for 7.2. Although people might still vote
>>> for it, the RFC needs to be explicit about which version it is for.
>>> 
>>> 
>> In my opinion it's too late for 7.2 especially as it contains an ABI
>> break which at best will be annoying for the folks helping us test.
>> The primary vote should be about 7.3 and if this wants to land on 7.2
>> there should be a separate vote for that.
>> 
>> -Sara
> 
> 
> -- 
> 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] samesite cookie implementation

[Lars Strojny]

Hi everybody,

 

I strongly believe this is something we should ship with 7.2. That would give 
the ecosystem a 1-year head with a feature that could eventually help eradicate 
CSRF. I would argue that this is worth the unorthodox circumnavigation of our 
policies. Do you think that’s outrageously crazy?

 

cu,
Lars

 

On 24.07.17, 10:53, "Frederik Bosch | Genkgo"  wrote:

 

LS,

 

Because of the valid arguments to set(raw)cookie and 

session_set_cookie_params to become lengthly functions, I reconsidered 

the proposal. It now consists of two possibilities. One is add samesite 

as argument and second one is to have these functions accept an array of 

options. One can read the changes in the proposal 

https://wiki.php.net/rfc/same-site-cookie.

 

When both solutions will be rejected, the floor will be completely open 

for the proposal of http_cookie_set/remove since we then investigated 

all the possible solutions to the current set of functions.

 

Best,

Frederik

 

 

 

On 20-07-17 10:10, Frederik Bosch | Genkgo wrote:

 

LS,

 

All concerns that have been put forward are updated in the RFC 

document. See https://wiki.php.net/rfc/same-site-cookie. I am going to 

start the voting on August 1, 2017. Exactly two weeks after I posted 

the RFC on the internals list. If new concerns are put forward in the 

meanwhile, I will of course update the RFC.

 

Best,

Frederik

 

 

 

 

On 19-07-17 17:06, Andrey Andreev wrote:

Hi,

 

Not realizing I was looking at EOL dates, I (unintentionally) provided

some wrong info yesterday:

 

On Tue, Jul 18, 2017 at 5:13 PM, Andrey Andreev  wrote:

- HttpOnly was released with PHP 5.2.0 in January 2011 - just 3 months prior

to IETF RFC 6265 (April 2011) becoming a standards track.

PHP 5.2 was of course released way back, in 2006. My apologies for that.

 

Cheers,

Andrey.

 

-- 

 

 

 Frederik Bosch

 

 

   Partner

 

Genkgo logo

Mail: f.bo...@genkgo.nl 

Web: support.genkgo.com 

 

Entrada 123

Amsterdam

+31 208 943 931

 

Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder 

nummer 56501153

 

-- 

 

 

Frederik Bosch

 

 

  Partner

 

Genkgo logo

Mail: f.bo...@genkgo.nl 

Web: support.genkgo.com 

 

Entrada 123

Amsterdam

+31 208 943 931

 

Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer 

56501153

 

Re: [PHP-DEV] Missing reflection info about strict types?

[Lars Strojny]

> On 07 Sep 2016, at 10:13, Leigh  wrote:
> 
> On Mon, 5 Sep 2016 at 10:39 Nicolas Grekas  wrote:
[...]
> As an aside, would you guys like to see a strict types indicator in debug
> backtraces? I wrote a small patch for it back during development of 7, and
> then forgot about it.
> 
> https://github.com/lt/php-src/commit/ac1171a81df814ad0042ef5989010bfe7d3e1652

Looks very useful. Maybe we want to add this to stack trace strings as well.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Lars Strojny]

Hi Davey,

thanks for the proposal and excuse my rather longish reply already.

> On 02 Sep 2016, at 21:32, Davey Shafik  wrote:
[...]
> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
> in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+)
> in their place.
[...]

Before discussing the proposal, I wanna go back one step and disaggregate the 
main use cases of what pear does so far (I simplified that a bit, but look at 
pear help on your own):

 - Install PHP extensions written in C/C++ through pecl and pecl.php.net
 - Install PHP libraries written in PHP through pear.php.net
 - Act as a version manager for both C and PHP based extensions/libraries
 - Package pecl packages for release

Probably less used (my guess!):
 - Building an RPM spec file from a PEAR package
 - Adding additional PEAR channels to install more dependencies than what is on 
pecl.php.net and pear.php.net
 - Signing packages
 - I’ve heard there might be a web interface somewhere but I have no idea about 
it :)

I believe out of those use cases there should only be two that are supported in 
core:

 1) Install PHP extensions written in C/C++ based on a global repository like 
pecl.php.net (or it’s successor)
 2) Tooling for maintaining such PHP extensions written in C/C++

Note: The second one could be solved in userland but I think for convenience 
reasons this should be supported by core.

For a healthy ecosystem we want to have alignment but also competition on 
central pieces of infrastructure like composer is. Don’t get me wrong, composer 
was programmer-heaven-sent and I love using it but if somebody has a better 
idea I don’t want core to provide relative competitive advantage just because 
it’s bundled. Maybe if PHP would not have shipped pear it would be long gone. 
Also I would argue that the lifecycle of a package management tool is different 
than the lifecycle of language, meaning that a package management needs more 
upgrades than the language so bundling doesn't really fit.

Having said that, I think we should offer an easy way to install composer in 
the core as a practical, convenient and realistic compromise. Something like 
php --composer-install that basically does curl getcomposer.org/composer.phar > 
/usr/local/bin/composer && chmod +x /usr/local/bin/composer. If we want to get 
fancy even a script that replaces itself with the content of 
getcomposer.org/composer.phar. This could also include a policy that we would 
include competing package managers if they proof a certain level of traction in 
the same way.

Now for pickle specifically: as I have never used it personally I have no way 
to judge it’s stability or defect rate. I would love to hear an opinion on that 
from people with more experience here. Also what about traction: looking at the 
commit history of the project, could some of the authors chime and provide some 
perspective on wether it's more or less done, what the development roadmap (if 
any) looks like and what would be caveats of including it.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Lars Strojny]

Hi Yasuo,


> On 31 Aug 2016, at 21:45, Yasuo Ohgaki  wrote:
[...]
> Thank you for voting!
> The RFC is declined 1 vs 13
> A bit surprised this result.
> 
> I requested the reason of objection, but many of them does not disclose why.
[...]
> lstrojny (lstrojny)
[...]

sorry for not chiming in earlier, but I indeed owe you an explanation. I 
believe making ext/filter a part of PHP created more trouble than it solved, 
even though I applaud it’s intention. Of course, filtering and validation are 
necessary essentials of any secure web application. I nevertheless strongly 
believe validation and filtering must live in userland.
Validation and filtering are often very much tied to the domain problem a user 
of PHP is to solving and the change rate of the application will be higher than 
the change rate of the language (hopefully). To give a more concrete example: 
let’s say our problem is we want to validate if a string is a valid domain 
because our business is registering domains. Nowadays, top level domains are 
introduced quite often and there is no way PHP could have a nice, up to date 
whitelist of TLDs all of the time and as a domain registration business it’s 
impossible for me to wait for the updated whitelist in PHP NEXT. That’s why I 
believe this is something that belongs to userland so the library that offers 
(domain) validation can follow a lifecycle that fits the problem it is trying 
to solve.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

[Lars Strojny]

Hi Alexander,


> On 17 Feb 2015, at 12:46, Alexander Lisachenko  
> wrote:
> 
> Hello, internals!
> 
> I want to introduce a RFC for providing a userland API for accessing an
> Abstract Syntax Tree of the source code and to provide userland parser
> hooks for source code modification:
> https://wiki.php.net/rfc/parser-extension-api

Looks cool and I could see a couple of interesting possibilities arising. One 
thing: any particular reason ExtensionInterface is static? I could see a couple 
of benefits having extensions carry state and registerExtension() taking an 
instance of ExtensionInterface, not a class name. What do you think?

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Lars Strojny]

Hi Matteo,

sorry for the late response.

> On 07 Feb 2015, at 12:46, Matteo Beccati  wrote:
> 
> Maybe it's just me, but I didn't quite understand the point you are making 
> here. Are you saying that declares are more or less like ini settings?

Yes, exactly that. The new declare()-statement will fundamentally change how 
the engine behaves and one will have two learn more or less two flavors of PHP. 
Even worse I am forced to use the PHP flavor the person picked who changed the 
declare() statement last.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Lars Strojny]

Hi Andrea,

> On 05 Feb 2015, at 21:14, Andrea Faulds  wrote:
> [...]
> Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In 
> addition to the vote on the main RFC, there is also a vote on the type 
> aliases issue, and a vote to reserve the type names for future RFCs’ sake if 
> this RFC fails.
> 
> The RFC can be found here, and it contains a voting widget: 
> https://wiki.php.net/rfc/scalar_type_hints

I realise how much effort you put into making scalar type hinting possible in 
PHP and I applaud you for that. Being a proponent of strict scalar type hinting 
I also understand the current RFC tries to find a compromise between both 
camps. It is probably the best we can come up with right now given we want to 
fullfill the following set of requirements:

 - Strict scalar hinting
 - Weak scalar hinting
 - Let the mode be chosen by the caller, not the callee

I nevertheless decided voting against it as I am afraid the current RFC would 
do more long-term harm to the ecosystem than not having scalar type hints. My 
main concern is that the declare statement is basically a better behaviour 
changing ini setting and PHPs history is paved with those. I very much hope for 
scalar type hinting, especially a strict variant but this is not what we should 
merge.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)

[Lars Strojny]

Hi Guilherme, hi Robert.

> On 01 Dec 2014, at 14:58, Robert Stoll  wrote:
> 
> I am not sure what makes more sense for PHP, but just as thought-provoking 
> impulse, wouldn't it be better just to check that all methods are static and 
> __construct private instead of turning methods magically into static methods 
> and __construct private?

I very much like the RFC in its current state except for the implicit static. 
While we can preserve the behaviour of automatically turning methods into 
static methods, this should indeed trigger a warning.

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

Re: [PHP-DEV] [RFC][Vote Cancellation] Return Types

[Lars Strojny]

Hi Levi,

thanks for doing "the right thing"[tm] and cancelling the vote to open up the 
discussion.

> On 07 Nov 2014, at 17:20, Levi Morrison  wrote:
[...]

> If these were split into separate files and autoloaded
> the current solution would work.
> 
>  class A {
>  function foo(): B {}
> }
> class B extends A {
>  function foo(): C {}
> }
> class C extends B {
>  function foo(): C {}
> }

I could see us documenting the behaviour as an existing limitation as I would 
guess that it will not be a huge issue in real life most likely anyway because 
of composer and PSR-1/PSR-4.

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

Re: [PHP-DEV] [RFC] Safe Casting Functions

[Lars Strojny]

Hi Derick,

> On 21 Oct 2014, at 17:26, Derick Rethans  wrote:
> 
> But what about if we also would like a to_bool, which would accept 
> "true", "false", "0", "1", true, false, 1 and 0?

Yep, I think that totally makes sense. "yes" and "no" would be further 
candidates but that’s probably already too much.

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

Re: [PHP-DEV] [RFC] Safe Casting Functions

[Lars Strojny]

Hi Andrea,

> On 21 Oct 2014, at 00:57, Andrea Faulds  wrote:
> 
> Good evening,
> 
> I am presenting a new RFC to add a set of three functions to do validated 
> casts for scalar types:
> 
> https://wiki.php.net/rfc/safe_cast
> 
> Please read it.


I like the proposal except for one thing: the functions returning false in case 
of an error. As the next logical function would be "to_bool()", I foresee a lot 
of trouble with regards to API design as returning false there either means 
successful cast to false or an error while casting. What about changing the 
functions to take an $isError variable as a second argument?

$value = to_string(1.2, $isError);
if ($isError) {
   ...
}

Alternatively one could do the same thing with an $isSuccess variable:

$value = to_string(1.2, $isSuccess);
if (!$isSuccess) {
   ...
}

Thoughts?

cu,
Lars



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

Re: [PHP-DEV] [RFC] Exceptions in the engine

[Lars Strojny]

Hi Nikita,

On 06 Oct 2014, at 23:53, Nikita Popov  wrote:
[...]
> As such I'm re-proposing this RFC for inclusion in PHP 7:
> 
>https://wiki.php.net/rfc/engine_exceptions_for_php7
> 
> The RFC text is essentially the same as previously, with the primary
> difference being that parse errors are now converted to exceptions as well.
> This was previously not possible due to limitations in the compiler design.

I very much like the idea of making fatal errors exceptions, so: thumbs up! Is 
there a way to introduce different exception classes for different errors. E.g.

 - UndefinedMethodException for stdClass::method()
 - NullPointerException for null::method()
 - UndefinedFunctionException for invalid_function()
 - etc.

They could all extend EngineException to have a common base class but I am sure 
we could find good abstractions for an exception inheritance tree.

What do you think?

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Little switch improvement: get the used variable

[Lars Strojny]

Hi Rowan,

On 26 Sep 2014, at 18:11, Rowan Collins  wrote:
[...]
> Without the additional guarantees provided by a purely functional 
> environment, that's really just inverting the function header and if 
> statement.
> 
> Adding an extra case to that still means repeating the operator, so isn't the 
> same as what I was talking about at all:
> 
> foo(N) when N>100 ->
>N ** foo(N-10);
> 
> foo(N) when N>0 ->
>N * foo(N-1);
> 
> foo(0) ->
>1.

That is true, for the guarding it is indeed syntactic sugar. Sugar that could 
probably help with optimisations as it makes reasoning easier from an 
interpreter perspective but still syntactic sugar.

> 
>> In Scala one could replicate the instanceof behaviour by defining multiple 
>> methods of the same name with different argument types.
> 
> Or, indeed, in most strongly typed languages; in OOP, polymorphism can be 
> exploited for the same purpose, e.g. using the Visitor Pattern. Again, I'm 
> not sure what this has to do with switch statements, except that overloading 
> and polymorphism can both allow you to factor out *any* if/switch statement, 
> if you so desire.

That is exactly my point: instead of "optimising" the switch/case construct 
which is good enough as if/elseif/else replacement I feel our time would be 
better spent on thinking of polymorphism, guards and pattern matching.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Little switch improvement: get the used variable

[Lars Strojny]

Hi everyone,

On 24 Sep 2014, at 23:17, Rowan Collins  wrote:

> switch ( $number ) use ( === ) {
[...]
> switch ( $age ) use ( < ) {
[...]
> switch ( calculate_age($birth_date, $departure_date) as $age_at_departure ) 
> use ( < ) {
[...]
> switch ( $product ) use ( instanceOf ) {

All of these examples are trying to reinvent concepts that can be solved with 
guards, pattern matching and overloading in other languages. In Erlang one can 
write the same function name multiple times and guard it ("when" in fact(N)) or 
match the value ("0" in fact(0)).

fact(N) when N>0 ->
N * fact(N-1);

fact(0) ->
1.

In Scala one could replicate the instanceof behaviour by defining multiple 
methods of the same name with different argument types.

So I would rather see us making method declarations more flexible to cover 
those use cases instead of shoving all the functionality into switch/case. Last 
time I checked the interpreter to try and introduce more features around method 
declarations, it looks incredibly hard to do in a way that performs well. What 
is our stance on adding advanced features around declaring methods?

cu,
Lars



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency

[Lars Strojny]

Hi everyone,

On 25 Sep 2014, at 17:27, Patrick ALLAERT  wrote:
[...]
> 
> I'm in favor of disabling for consistency as well, however, I wish a
> warning would be emitted.

Voted in favour of disabling as well but could easily live with the other 
option as everything is better then leaving the inconsistency there.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Argument unpacking - Multiple unpacks and trailing arguments

[Lars Strojny]

Hi Nikita,

Am 23.09.2013 um 21:33 schrieb Nikita Popov :
[...]
> An example of trailing arguments are array intersections and diffs using a
> custom compare function:
> 
>array_uintersect(...$arrays, $compare);
>array_udiff(...$arrays, $compare);
>// also array_intersect_uassoc and all those other variations on the
> topic
> 
> Some people expressed concern about allow both usages (multiple unpacks /
> trailing args). I have a bit of a hard time understanding this (as there
> clearly are practical applications for both), so I'd appreciate some more
> opinions on the topic.

Although it might allow users to shoot into their foot, I prefer having it 
instead of introducing a limitation that is not technically necessary. So +1

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] RFC: Anonymous Classes

[Lars Strojny]

Hi Joe,


Am 23.09.2013 um 19:22 schrieb Joe Watkins :
[...]
>  As I have said, serialization does work, and unserialization does work ...
> 
>  Classes do have unique names, so as long as the entry is present upon 
> unserialize you will get the object you expect ... if the entry is not 
> present unserialization will fail silently.
> 
>  The same kind of thing can happen where you have declared a class based on 
> some predicate, whose value has changed upon unserialize and so the entry is 
> not present ...
> 
>  I'm not sure it is necessary to force any particular behaviour for 
> serialization, it depends entirely on the application whether or not the 
> entry is present upon serialization, it should be left down to the programmer.


it would make sense to forbid serializing anonymous classes like we forbid 
serializing closures. What do you think?

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] RFC: Anonymous Classes

[Lars Strojny]

Hi Joe,

what about serialization for those classes?

cu,
Lars

Am 23.09.2013 um 08:39 schrieb Joe Watkins :

> Morning All,
> 
>https://wiki.php.net/rfc/anonymous_classes
> 
>I'd like to hear thoughts regarding the addition of anonymous classes, 
> patch included.
> 
> Cheers
> Joe
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Request #65501 uniqid(): More entropy parameter should be true by default

[Lars Strojny]

Hi Nikita,

Am 24.08.2013 um 12:08 schrieb Nikita Popov :
[]
> We already have a great (version 4) UUID implementation called
> mcrypt_create_iv, just minus the fixed sequences and fancy formatting.
> Apart from moving this to core (not requiring mcrypt/openssl) and maybe
> adding alphabet support, I don't immediately see why this wouldn't be
> sufficient. Why do we need fancy UUID formatting or "unique hashes"
> (whatever that is supposed to be...)?

mcrypt_create_iv() is great but it is about usability: not every user of the 
language can create a UUIDs from mcrypt_create_iv() and we should make it as 
easy as possible to generate unique IDs. That said, a simple uuid($version) 
function would not hurt the core. I would argue that this is very similar to 
the password_hash() API. It was possible before the password API to store 
password securely, but we made it way easier now, which is a very good thing.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] Request #65501 uniqid(): More entropy parameter should be true by default

[Lars Strojny]

Hi everyone,

adding UUID functionality to the core would be very cool. Especially in times 
where we create more and more primary keys in the code, not in the database.

cu,
Lars

Am 23.08.2013 um 23:53 schrieb Yasuo Ohgaki :

> Hi David,
> 
> On Fri, Aug 23, 2013 at 12:03 PM, David Muir  wrote:
> 
>> Well, there's this:
>> 
>> http://pecl.php.net/package/uuid
>> 
> 
> I meant UUID module for source distribution. Sorry, I should have mentioned
> this.
> 
> PECL's UUID module is LGPL, so the license is needed to be changed.
> It uses ext2util lib. I suppose it would be Linux only module.
> 
> OSSP seems to have PHP module and it's MIT. We may copy it.
> Any issue copying it? This would be the easiest.
> 
> Or we can write PHP licensed module from scratch. It's a simple wrapper.
> People in this list can write it easily.
> 
> The last option is most preferred, IMO.
> 
> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [RFC] Constant Scalar Expressions

[Lars Strojny]

Super cool, thanks!

Am 13.08.2013 um 18:12 schrieb Anthony Ferrara :

> Hello all,
> 
> I'd like to propose a new RFC for 5.NEXT:
> 
> https://wiki.php.net/rfc/const_scalar_expressions
> 
> This allows for defining constant expressions which are resolved at compile
> time.
> 
> for example:
> 
> const FOO = 1 + 1;
> static $bar = 1 << 2;
> function foo($a = 1 | 2) {}
> class foo {
>public $bar = 1 << 2;
> }
> 
> Thoughts?
> 
> Anthony



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] RFC: constructor argument promotion

[Lars Strojny]

Hi Sean,

thanks for your answers.

Am 08.08.2013 um 02:54 schrieb Sean Cannella :

> It does in the sense the same way as the current mode "enforces" types on
> properties. That is, there's no guarantee that types will remain as
> initially set, only that the values passed to the constructor must be X
> type, ergo the post-ctor values of the props will be of type X. I can see
> the argument that it suggests real (permanent) typing where none exists
> though.
[...]
Makes sense. Given that, I don’t feel the shorter syntax is worth the WTF :)

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] RFC: constructor argument promotion

[Lars Strojny]

Hi Sean,

thanks for the RFC. Two other questions additionally to what Stas askes:

 - What about class type hints and array type hints?
 - If type hints are possible, doesn’t it look too much as real property type 
hinting?

cu,
Lars

Am 07.08.2013 um 21:47 schrieb Sean Cannella :

> Everyone -
> 
> Hi! Since this is my first post to this list, I'll introduce myself:
> I'm an engineer who has been working on HipHop VM in New York for the last 
> half year or so after a long time working at Microsoft on business software 
> and services in multiple hemispheres.
> 
> I wanted to get the PHP community's opinion on this feature. See the draft 
> RFC and referenced implementation below:
> 
> https://wiki.php.net/rfc/constructor-promotion
> 
> What do you all think?
> 
> Thanks,
> Sean Cannella | Facebook Eng
> If you are smart and persistent, you may find the truth. It is not always a 
> reward.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] RFC: Protocol Type Hinting

[Lars Strojny]

Hey Anthony,

thanks for your work and I think it’s a very good idea. I thought very much of 
it during the last days and I start to see its merits. So, good thing. I would 
prefer ~Type for syntax over  though, but that's just a minor detail.

cu,
Lars

Am 25.06.2013 um 17:57 schrieb Anthony Ferrara :

> Hey all,
> 
> I want to throw out this draft RFC to get the concept floating around and
> get feedback early.
> 
> https://wiki.php.net/rfc/protocol_type_hinting
> 
> There are still open questions, and a more complete (and cleaner)
> implementation will be needed before officially proposing it, but I wanted
> to get the concept out as soon as possible.
> 
> What do you think?
> 
> Thanks!
> 
> Anthony


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

Re: [PHP-DEV] Internal object orientation documentation available!

[Lars Strojny]

Thank you, thank you, thank you all!

Am 10.06.2013 um 20:33 schrieb Nikita Popov :

> Hi internals!
> 
> We just published some rather extensive documentation on internal object
> orientation:
> 
>http://www.phpinternalsbook.com/classes_objects.html
> 
> This is part of a larger project aimed at documenting the engine and making
> it accessible to new contributors.
> 
> Any feedback is appreciated!
> 
> Thanks,
> Nikita


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

Re: [PHP-DEV] supporting the final keyword for properties

[Lars Strojny]

Hi Ferenc,

Am 28.05.2013 um 08:15 schrieb Ferenc Kovacs :
[...]
>> I would like it to work the same way as it does in java(
>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4)
>> eg. you can set the initial value either in the declaration or later on,
>> but after it is set, you can't change it, trying to do that would create a
>> recoverable fatal error (or throwing an exception which extends
>> RuntimeException).
>> 
>> What do you think? Would this be viable? Is there any still-present reason
>> why we shouldn't support that?
[...]
> the accessors rfc got rejected, so I'm bringing this up again.

It’s a good idea in general but what about having it for variables as well? 
Could open interesting possibilities for an optimizer.

final $foo = "str";
$foo = "bar"; // bails out

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

Re: [PHP-DEV] property de-referencing

[Lars Strojny]

Hi Rasmus,

Am 25.04.2013 um 14:47 schrieb Rasmus Schultz :
[...]
> 
> What do you think?


I'm not sure about the operator character but the general idea is a good one. 
Do you have a patch as a POC?

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

Re: [PHP-DEV] Continued try blocks

[Lars Strojny]

Hi Julien,

I'm still on the fence, not sure if it isn’t too opaque.

Am 26.04.2013 um 16:41 schrieb Julien Pauli :
[...]

One question regarding scoping: does the next statement inherit the scope of 
the catch block like this?

try {
   $user = $repository->findById(123);
   $user->setName($name);
   $em->save($user);
   return true;
} catch (NotFoundException $e) {
   $user = new User();
   continue;
} catch (ValidationException $e) {
   $user->setName($this->stripInvalidChars($name));
   continue;
} catch (PersistenceException $e) {
   return false;
}

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

Re: [PHP-DEV] DateTimeImmutable

[Lars Strojny]

Hi Derick,

Am 27.03.2013 um 21:53 schrieb Derick Rethans :

> On Tue, 26 Mar 2013, Michael Wallner wrote:
> 
>> providing DateTimeImmutable as a sibling to DateTime.
> 
> That's fine with me, but I am not having the time to work on a patch 
> right now.

Happens. Let’s revert it till somebody finds some time to do it. Could you 
revert it?

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

Re: [PHP-DEV] RFC ? gethostbyname - getnameinfo()

[Lars Strojny]

I agree, PHP should have world-class support for v6. What is your proposal 
exactly?

Am 27.03.2013 um 13:39 schrieb Sam Hermans :

> Hi,
> 
> The rcf howto pushed me into mailing you guys to measure reaction. 
> 
> For a project i am working on i struggle a lot with the fact that 
> $_SERVER['REMOTE_ADDRESS'] return policy is to prefer IPv6 over IPv4, and 
> that gethostbyname prefers IPv4. It seems that the gethostbyname
> function as used in php is deprecated, and that getnameinfo should be used.
> 
> I think that in an age where we are finally getting the support of the *big* 
> boys to start using IPv6 that php should be there and ready for them.
> 
> I have never contributed to php core before, but i'm more than happy to take 
> the lead on this one.
> 
> Please let me know what you guys think, and thank you for your time.
> 
> Kind regards,
> Sam Hermans
> 
> 
> --
> 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] DateTimeImmutable

[Lars Strojny]

Not really, as an interface guarantees behavior, which is not possible for 
DateTimeImmutable and DateTime.

Am 27.03.2013 um 09:03 schrieb Ferenc Kovacs :

> 2013.03.26. 20:29, "Michael Wallner"  ezt írta:
>> 
>> Hi all!
>> 
>> I am concerned by the introduction of DateTimeImmutable extending
>> DateTime, and despite not being the talking guy, I'll try to outline
>> the reasons why I and obviously a lot of other people think so.
>> 
>> I can understand the frustration with a DateTime that should not have
>> been modifiable in the first place and the wish to improve upon things
>> and to lead users to the proper way. But, this is not the right way.
>> 
>> If interoperability was in mind, it will not be given, because every
>> single API which has been written in the last seven years and has
>> DateTime in it's signature is potentially broken.  The code may and
>> should be able to expect a modifiable instance of DateTime, which is
>> no longer guaranteed.
>> 
>> The argument, that it was implemented this way, so that method
>> signatures do not have to be changed, is weak, because every method
>> has to be reviewed, and a method signature change would actually be
>> the right thing to accept a DateTimeImmutable, because it does not act
>> like a DateTime.
>> 
>> It will lead to lots of boilerplate typechecking code with instanceof
>> because it actually is not the same type. DateTimeImmutable extending
>> DateTime will instantly create BC issues, which we will suffer from a
>> long time.
>> 
>> The toughtful developer, which already cloned the DateTimes in his
>> methods won't benefit either, because now he's cloning
>> DateTimeImmutables.
>> 
>> In my opinion, the only way to "solve" this issue is through
>> documentation, advocation, publication and providing DateTimeImmutable
>> as a sibling to DateTime.
>> 
>> DateTime is here, and we cannot go back in time, but we might
>> deprecate DateTime* and introduce a date namespace in PHP-next to
>> clean up this front, but this already goes beyond the issue with
>> DateTimeImmutable.
>> 
>> 
>> --
>> Regards,
>> Mike
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
> 
> would it make sense to introduce an interface wich both DateTime and
> DateTimeImmutable implements?
> that way you can typehint for both if you know that both classes are fine
> for you.


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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Lars Strojny]

Start simple: ask Derick to revert and go through the usual RFC process.

@Derick: given the overall response on the list, could you revert the 
introduction of DateTimeImmutable?

cu,
Lars

Am 26.03.2013 um 01:21 schrieb Levi Morrison :

> So how do we officially undo something that didn't use an RFC but should
> have?


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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Lars Strojny]

Am 25.03.2013 um 21:23 schrieb Sebastian Bergmann :

> On 03/06/2013 10:50 AM, Nikita Popov wrote:
>> I'd prefer to have nothing over having something bad.

+1

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

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

[Lars Strojny]

Yay!

Am 07.03.2013 um 17:48 schrieb Zeev Suraski :

> The voting period ended, and the option selected with 44 out of 70 votes
> was integrating Optimizer+ into PHP 5.5.0, even at the cost of a minor
> delay.  An overwhelming majority (66 out of the 70 votes) was in favor of
> going with the integration in general.
> 
> 
> 
> We’ll work on moving the repository as soon as possible so that we can push
> out a new 5.5.0 package that includes it.  Another couple of things we need
> to tackle are .ini option naming (probably “opcache.” instead of
> “zend_optimizerplus.”) and default status (enabled or disabled by default
> by default).
> 
> 
> 
> Zeev
> 
> 
> 
> 
> 
> *From:* Zeev Suraski [mailto:z...@zend.com]
> *Sent:* Wednesday, February 27, 2013 6:13 PM
> *To:* 'PHP Developers Mailing List'
> *Subject:* [VOTE] Integrating Zend Optimizer+ into the PHP distribution
> 
> 
> 
> Based on the overwhelming response, the vote is now open J
> 
> 
> 
> https://wiki.php.net/rfc/optimizerplus
> 
> 
> 
> Voting ends March 7th.
> 
> 
> 
> Zeev


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

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

[Lars Strojny]

Hi Zeev,

Am 28.02.2013 um 21:16 schrieb Zeev Suraski :

> Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
> make it - there's truth to the assertion you wouldn't want them both at the
> same time.

That’s not entirely true. If you stay as similar as possible to your production 
environment, your development environment will have an opcode cache as well. 
And possibly xdebug.

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

Re: [PHP-DEV] Allow (...)->foo() expressions not only for `new`

[Lars Strojny]

Hi Nikita,

Am 25.02.2013 um 23:20 schrieb Bob Weinand :
[...]
>> When it comes to changing syntax, there is no such thing as too small
>> of an RFC IMO.  Runtime changes can occasionally be hand-waved, but
>> syntax changes are serious business.

I very much like it, it’s a good change. But can we have a (short) RFC 
nevertheless?

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Lars Strojny]

As a general reply: I’d like to disagree, and here is why. Yes, we should not 
let half baked features in but we need to add more and more features, also 
syntax wise. For three reasons:


 - Parity/expectations/me too: so you can do that in PHP as well
 - Expressiveness: allow better ways to express the same idea in more concise 
ways
 - Innovation: bring unexpected features to the language people didn’t even 
expect


Let’s recall a few of the latest additions:


 - 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, which 
in turn provides the foundation for the even more awesome stuff composer is.
 - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am 
sure there is somebody out there :)
 - 5.3: Closures, huge thing for us, a matter of parity to other languages. 
Really changes the face of a lot of APIs (see e.g. Doctrine transactional(), 
the whole micro framework movement, React)
 - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a 
little meh. But it was good we waited and got it right.
 - 5.4: Short array syntax. A parity/culture issue.
 - 5.4: Traits, I am happy we got horizontal reuse right
 - 5.4: array dereferencing. Very small but useful. To me it feels more like a 
bugfix
 - 5.4: callable type hint. Small change with a huge impact
 - 5.5: Generators, also a matter of parity and a matter of awesomeness
 - 5.5: ClassName::class syntax. A really good improvement to the overall 
usability of namespaces. Just imagine how much shorter unit test setUp() 
methods will become


What we have on our list that, from my perspective, will sooner or later hit us:


 - Property accessors in some form or another: a lot of people seem to like it.
 - Annotation support: we would have a lot of customers for it.
 - Autoboxing for primitives. Allows us to fix a lot of problems in 
ext/standard.
 - Unicode. Obviously.
 - Named parameters. A recurring topic might be a topic worth digging deeper.
 - I'm positive the Generics discussion will arise at some point again.


… and these are just the changes on a syntax/semantics level, I'm not talking 
about all the awesome technologies (one of which you are working on) we need to 
integrate tighter and eventually bundle with core. I don’t believe we should 
let our users outgrow the language, quite the opposite, we should grow with our 
users and the broader web community, otherwise we will fail. PHP is nowadays 
used for tasks it never was intended to be used but that’s a good thing. We 
need to continuously adapt. What’s true for software projects is true for 
languages: stop improving actually reduces its value over time.

cu,
Lars

Am 20.02.2013 um 19:18 schrieb Derick Rethans :

> Looks like it is time to forward this email from 2006 again:
> 
> -- Forwarded message --
> Date: Thu, 09 Mar 2006 12:57:32 +0200
> From: Zeev Suraski 
> To: internals@lists.php.net
> Subject: [PHP-DEV] Give the Language a Rest motion
> 
> I'd like to raise a motion to 'Give the Language a Rest'.
> 
> Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
> and 2 more major versions since then, and we're still heatedly debating on
> adding new syntactical, core level features.
> 
> Is it really necessary?  I'd say in almost all cases the answer's no, and a
> bunch of cases where a new feature could be useful does not constitute a good
> enough reason to add a syntax level feature.  We might have to account for new
> technologies, or maybe new ways of thinking that might arise, but needless to
> say, most of the stuff we've been dealing with in recent times doesn't exactly
> fall in the category of cutting edge technology.
> 
> My motion is to make it much, much more difficult to add new syntax-level
> features into PHP.  Consider only features which have significant traction to 
> a
> large chunk of our userbase, and not something that could be useful in some
> extremely specialized edge cases, usually of PHP being used for non web stuff.
> 
> How do we do it?  Unfortunately, I can't come up with a real mechanism to
> 'enforce' a due process and reasoning for new features.
> 
> Instead, please take at least an hour to bounce this idea in the back of your
> mind, preferably more.  Make sure you think about the full context, the huge
> audience out there, the consequences of  making the learning curve steeper 
> with
> every new feature, and the scope of the goodness that those new features 
> bring.
> Consider how far we all come and how successful the PHP language is today, in
> implementing all sorts of applications most of us would have never even 
> thought
> of when we created the language.
> 
> Once you're done thinking, decide for yourself.  Does it make sense to be
> discussing new language level features every other week?  Or should we, 
> perhaps,
> invest more in other fronts, which would be beneficial for a far bigger
> audience.  The levels above - extensions to keep with

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

[Lars Strojny]

Hi,

Am 20.02.2013 um 06:24 schrieb Laruence :

> On Tue, Feb 19, 2013 at 8:06 PM, Sara Golemon  wrote:
>> Opening RFC to allow trailing comma in function call argument lists
>> 
>> https://wiki.php.net/rfc/trailing-comma-function-args

-1 on this as well. If you don’t like the diffs, fix the diff implementation to 
ignore trailing comma changes. But I guess I'm in a minority here and it is 
easy to prevent stuff like that with a code sniffer rule.

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

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

[Lars Strojny]

Hi Marcello,

Am 19.02.2013 um 14:51 schrieb Marcello Duarte :

> Thanks for the feedback. I get most people here don't appreciate the value of 
> the feature.
> 
> I can understand that If you haven't tried to write a tool like capistrano, 
> rspec, chef, puppet, etc, etc in PHP you probably won't see much value in 
> implementing such things.
> 
> On 19 Feb 2013, at 13:19, Derick Rethans wrote:
>> On Tue, 19 Feb 2013, Marcello Duarte wrote:
>> 
>>> Inspired by Sara, here is another RFC, I finally got around to draft:
>>> 
>>> https://wiki.php.net/rfc/short-syntax-for-anonymous-function

I don’t like the syntax, but the proposal in general. If you compare PHPs 
syntax to various others, it is indeed clumsy.

Python:
map(lambda v: v * 2, [1, 2, 3])

Ruby:
[1, 2, 3].map{|x| x * 2}

Scala:
List(1, 2, 3).map((x: Int) => x * 2)

PHP:
array_map(function ($x) {return $x * 2;}, [1, 2, 3]);

So even a statically typed language like Scala is shorter and better to read. A 
good improvement would be implicit return and getting rid of the function 
keyword.

array_map(($x): $x * 2;, [1, 2, 3]);

But this RFC should come with a patch, otherwise we are discussing things that 
aren’t necessarily easy to implement.

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

Re: [PHP-DEV] PHP 5.5 upcoming roadmap

[Lars Strojny]

Hi David,

thanks for the clarification, sounds like a plan :-) I'm not opposed to 
including O+, quite the opposite but I want us to stick to our process.

cu,
Lars

Am 15.02.2013 um 19:14 schrieb David Soria Parra :

[...]

>> I'm sorry, but you must be kidding doing such a change and skipping
>> the RFC process altogether. This will seriously hurt the acceptance
>> of the whole RFC process and there won’t be a good argument against
>> people just committing random changes without an RFC. How should I
>> convince somebody with a working pull request to go ahead and deal
>> with an RFC when we introduce changes like that "just like that".
>> 
>> Can we please stop the process insanity and stick to our own rules
>> (or change them in a transparent way).
>> 
>> Thanks, Lars
>> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRHnsjAAoJEKSanlo0ToXKmXAP/AuKTYfcm3PZdrOu9nqDkg8x
> IjnsY5pMybDTbkJtLw96DT+5Zz24t9BdwBPwTRkKccLiYGavCQvV+ewdNUMEFrv7
> kbuyi6tgRbB/aUpocKXbzq5CRk19YcIZr3E4HXpeMHcNhXGbFRmXvk8yMUWlTGMn
> Fsf6v9bs+4d/uCaSMr2jS56KgDTn9pseAbeDumj3L+EAZYF+k/lz0YuxNC7X3EUv
> HclKiPBLroaYz0q4Yg+BHuBsCgkhGnzwxNlYfkCPHh8mZZFxUtcIkONgILgxsGMA
> +ik51JzspZRkdvr+TpvE6Va5O52i3C31wxKelr4f2+dgDO7v28tqOxrOHYVZgpdY
> NK3GOYDgp1YgphY0CY/J0IrK2yLjdqois7qynuyAwP7DxE/ytz6HFs4UuzPdM6Ry
> sFXua/L5JFzHHO4jU1x47BDM/Blre2COQaMdB1GE2hgFIjKqU5cQRHxMG6VzGCct
> UiWik8/1sLQKoMFQnSMBHbidlYbDCKd4kW2dyKjKw9Ok3MfW08VPZ/SBJNB2RDYP
> aYD4OcVe9SE9kuJEP0sxs9f/s4xMmkiP6AYa/2e2L4UqfoT0bo20HrrA50h0lKXb
> hkj/yOWB9f6qy3qUhDK5EdbSPK5i18cS5jWcseXLjHlE/xADWGrTyjAg2flaKAQT
> xF5/opO8pfoi4PY6osQT
> =iZJN
> -END PGP SIGNATURE-
> 
> -- 
> 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] PHP 5.5 upcoming roadmap

[Lars Strojny]

Hi Julien,

Am 15.02.2013 um 13:05 schrieb Julien Pauli :

> Hello everyone,
> 
> As you may know, Zend recently open sourced ZendOptimizer+ with a PHP
> Licence.
> We are planning to merge it to PHP5.5 Core (discussions on Mailing lists
> and IRC) and have it bundled with PHP5.5 final release stable.

I'm sorry, but you must be kidding doing such a change and skipping the RFC 
process altogether. This will seriously hurt the acceptance of the whole RFC 
process and there won’t be a good argument against people just committing 
random changes without an RFC. How should I convince somebody with a working 
pull request to go ahead and deal with an RFC when we introduce changes like 
that "just like that".

Can we please stop the process insanity and stick to our own rules (or change 
them in a transparent way).

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

Re: [PHP-DEV] Github pull request management

[Lars Strojny]

Hi Johannes,

quick question: does it automatically open bug reports for each PR?

Am 13.02.2013 um 17:03 schrieb Johannes Schlüter :

> Hi,
> 
> with Felipe's help I've just added the second pull request management
> tool to mange pull requests.
> 
> The first one is https://qa.php.net/pulls/ this allows any php.net
> developer to close pull requests on github, without us having to manage
> users on github and adding them to groups and all that stuff. I guess
> most of you have seen that.
> 
> The new one is a simple integration of pull requests to the bug tracker.
> Similar to the "patch" feature of the bug tracker it is meant to link
> pull requests from bugs so one can easily use a quick search to find all
> bugs with code waiting for a review and having php.net users assigned to
> pull requests.
> 
> Search for recent bugs with patch or pull request:
> https://bugs.php.net/search.php?boolean=0&limit=30&order_by=id&direction=DESC&cmd=display&status=Open&bug_age=0&bug_updated=0&bug_type=All&patch=Y&pull=Y
> Search for recent bugs with pull requests only:
> https://bugs.php.net/search.php?boolean=0&limit=30&order_by=id&direction=DESC&cmd=display&status=Open&bug_age=0&bug_updated=0&bug_type=All&pull=Y
> 
> This is a relatively quick hack with room for improvement, some ideas
> anybody can pick up (I'm happy to give a hand where needed):
> 
> - Add functionality from qa.php.net/pull for closing pull requests
> - Add a note to github when a bug is assigned to a pull request
> - Show more details about the pull request
> - Improve the usability
> - Improve the code
> - ...
> 
> Happy bug fixing!
> 
> johannes
> 
> 
> 
> -- 
> 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] Status of pull request

[Lars Strojny]

Hi Jason,

thanks for the reminder.

Am 13.02.2013 um 14:03 schrieb Jason Gerfen :

> Is it considered spamming the list to check the status of a pull request? I
> am going to ask any ways, hope it doesn't offend.
> 
> The pull request addresses bug fix/feature request #38917 implementing
> native signed public key & challenge support to the OpenSSL extension.
> Details can be found @ https://github.com/php/php-src/pull/267
> 
> (I created a new branch 'issue-38917-spkac' according to the Wiki, but does
> not seem to be in the list of branches anylonger)

I'm personally don't feel comfortable enough to mess around in ext/openssl. 
Could somebody else please have a look?

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

[PHP-DEV] New SSL stream context option to prevent CRIME attack vector

[Lars Strojny]

Hi,

we have an open PR for a new SSL stream context option to prevent the CRIME 
attack vendor. Anybody with more familiar knowledge of SSL should have a look: 
https://github.com/php/php-src/pull/269

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

Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

[Lars Strojny]

Hi Zeev,

Am 29.01.2013 um 15:21 schrieb Rasmus Lerdorf :

> On 01/29/2013 06:13 AM, Nikita Popov wrote:
> 
>> I'm not sure I fully understand this. The RFC claims that Optimizer+ is
>> already *now* fully compatible with PHP 5.5. And that it was also
>> compatible when PHP 5.4 was released. So they lack of a working and free
>> opcode cache clearly wasn't the issue. My guess is rather that the lack
>> of APC support (as in specifically APC and not just some opcode cache)
>> was an issue. Either because people didn't know about alternatives (APC
>> after all is the go-to opcode cache), didn't want to try them or had
>> software tightly integrated with APC (and in particular its user cache).

[...]

I personally find it quite cool, that Zend considers open sourcing its 
Optimizer+ product. I’m obviously just guessing, but I am halfway sure, that 
APC (and XCache etc.) have a lot to do with Zend being willing to do that move. 
In a sense that it helped making opcode caches a commodity. Maybe that’s a 
small solace for the countless hours that where spent on APC. To get more 
practical, I see the following steps going forward:

 1.) Zend releases a first open sourced version of Optimizer+ on PECL (or 
somewhere else)
 2.) We as a community can have a look at the code
 3.) We vote on the RFC
 3a.) Question a) Should Optimizer+ be included in core: yes/no
 3b.) Question b) If yes, may the inclusion delay 5.5 by X month: yes/no
 4.) The proposers make sure it works with ZTS as well (this obviously doesn’t 
exclude help from outside contributors)

@Zeev, out of interest, how much time does Zend plan to spend on maintaining 
Optimizer+ in the core for the foreseeable future?

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

Re: [PHP-DEV] Patch: Specify temp directory

[Lars Strojny]

Hi Alex,

could you open a pull request on GitHub for it. Makes managing things much 
easier. Other than an outstanding review, I see no reason not to include this 
functionality.

cu,
Lars

Am 18.01.2013 um 15:01 schrieb ALeX Kazik :

> Hi,
> 
> some time ago I created a small patch to make it possible to specify
> the temp dir by the php.ini.
> 
> It can be found here:
> https://bugs.php.net/bug.php?id=60524
> (my latest patch (against 5.4.3) also works for 5.4.11 and 5.5.0a3)
> 
> Now I do wonder if anything will happen or if that's it?
> 
> I would really appreciate if the patch would be included and hopefully
> also some other people.
> 
> Regards,
> ALeX.
> 
> -- 
> 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] [VOTE] array_column() function

[Lars Strojny]

It’s quite simple: 

 - Do you want to include the functionality: yes/no
 - If you want to include it, which name should it have: 
array_column/array_pluck

Am 14.01.2013 um 23:23 schrieb Gustavo Lopes :

> On Mon, 14 Jan 2013 23:16:52 +0100, Pierre Joye  wrote:
> 
>> On Mon, Jan 14, 2013 at 11:01 PM, Ben Ramsey  wrote:
>> 
>>> I've already removed the array_pluck() alias. Unfortunately, after removing 
>>> the alias, it appears that some have changed their votes from "yes" to 
>>> "no," because they preferred the other function name.
>>> 
>>> That said, I'm not going to call for a vote on the function name at this
>>> time. The predominant sentiment on the list was for it to have one function 
>>> name or the other, but not both, so I've updated the pull request
>>> accordingly.
>> 
>> Up to you, but I'd to suggest again to re do the vote and add the
>> naming option, easy, clear, open.
>> 
> 
> I don't think either easier or clear. Then all sort of questions come up if 
> none of the three options has an absolute majority. And if you open two 
> separate and concurrent votes you're taking from people the power to 
> condition the vote on a specific choice of name.
> 
> Personally, I don't care about the name as long as only one is chosen (no 
> alias).
> 
> -- 
> 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] [VOTE] array_column() function

[Lars Strojny]

Hi Ben,

Am 14.01.2013 um 23:16 schrieb Pierre Joye :
[...]
> Up to you, but I'd to suggest again to re do the vote and add the
> naming option, easy, clear, open.

I was one of the people changing from yes to no because of the name. I like the 
functionality but I prefer no new array function over one with yet another 
strange name.

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

Re: [PHP-DEV] [VOTE] array_column() function

[Lars Strojny]

Nope, it wasn’t rejected, there was simply no response for a really long time: 
https://github.com/php/php-src/pull/202

Am 14.01.2013 um 22:06 schrieb Herman Radtke :

> On Sat, Jan 12, 2013 at 12:04 AM, Levi Morrison  
> wrote:
>> The real problem here (in my opinion) is that `array_filter` does not
>> pass the key information to the callback. If you could do that, you
>> could select columns that way.
> 
> I opened a PR with this feature, but it was rejected.
> 
> -- 
> Herman Radtke
> @hermanradtke | http://hermanradtke.com
> 
> -- 
> 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] Bug #23815: Added extra ImageCopyMergeAlpha function

[Lars Strojny]

Any news?

Am 04.01.2013 um 13:45 schrieb Pierre Joye :

> No need to create another function for that. I will do it once I am back at
> work next week.
> On Jan 3, 2013 12:33 PM, "Lars Strojny"  wrote:
> 
>> No objection from my POV. Going to merge it in around a week, if no one
>> objects.
>> 
>> Am 02.01.2013 um 10:35 schrieb matt clegg :
>> 
>>> I have added ImageCopyMergeAlpha as an extra function to resolve bug
>> 23815.
>>> 
>>> I have created a pull request on github
>>> https://github.com/php/php-src/pull/211
>>> 
>>> Can this be merged into 5.5? And, what do I need to do?
>>> 
>>> --
>>> 
>>> 
>>> Matt Clegg
>>> 
>>> --http://mattclegg.com/
>> 
>> 
>> --
>> 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] [VOTE] array_column() function

[Lars Strojny]

Hi Ben,

Am 12.01.2013 um 01:17 schrieb Ben Ramsey :

> I've opened voting for the array_column() function RFC.
> 
> You can vote at https://wiki.php.net/rfc/array_column#voting

I voted yes, but I prefer to call it just array_pluck (no aliases). It’s what 
underscore.js calls it and my own pet project functional-php calls it 
Functional\pluck() as well. What do you think?

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

Re: [PHP-DEV] A remark about PHP's Vision and new things.

[Lars Strojny]

Hi Stas,

I think you hit a nail here. 

Am 10.01.2013 um 21:36 schrieb Stas Malyshev :

> Another thing is that we're not having some features that are used
> extensively in C# annotations, main being named parameters support.

To make sure we are not providing a somewhat cumbersome implementation, let’s 
start tackling named parameters first. It’s another long standing feature. We 
will most likely need named parameters for convenient annotations anyway. We 
have an (really old) RFC for that: https://wiki.php.net/rfc/namedparameters.

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

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Lars Strojny]

Hi Yahav,

Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar :
[...]
> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be great.
> 
> So, I've created an RFC that propose to improve the Reflection extension by
> adding the ability to read annotations decorated in the doc-comment.
> 
> https://wiki.php.net/rfc/reflection_doccomment_annotations
> 
> What is your opinion about this?


From what I've seen in various components using annotations, this kind of 
support wouldn’t be enough. I would much prefer direct mapping of a single 
annotation on a class including a way to define properties and such. This is 
how e.g. Doctrine, Symfony, Zend Framework etc. all utilize annotations 
nowadays.

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

Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading

[Lars Strojny]

Hi Stas,

Am 06.01.2013 um 06:38 schrieb Stas Malyshev :
[...]
> Following the recent discussion on the list, I've drafted an RFC
> describing the CurlFile solution for it here:
> 
> https://wiki.php.net/rfc/curl-file-upload
> 
> Please review and comment. If there's a general positive feedback, I'll
> try to implement a patch for it pretty soon.

Couldn’t CurlFile extend SplFileInfo? Otherwise it looks good.

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

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

[Lars Strojny]

Hi Clint,

got it. 

Am 04.01.2013 um 16:28 schrieb Clint Priest :

> Uhm.. brain fart.
> 
> I was thinking $this->$foo was normal when I wrote this up, I would change my 
> last statement from the earlier email to any syntax which did not include a $.
> 
> That being said then, I think I favor parent->foo the best.

It’s not really a matter of syntax, but a matte of principle. We shouldn’t 
burden our users with another syntax to achieve the same thing.

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

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

[Lars Strojny]

Hi Clint,

Am 04.01.2013 um 04:13 schrieb Clint Priest :
[...]
>   1) It forces the user to access the parent property accessor in a different 
> way than is used everywhere else

Isn’t that the same as parent->$foo? Please let’s not introduce a special 
syntax for something that can be done properly. I would either go with variant 
2 ("Rewrite the way static property references work"). If that takes too long 
and we feel that a version without parent access is sufficient, we should 
disallow parent access for version 1 of property accessors.

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

Re: [PHP-DEV] Bug #23815: Added extra ImageCopyMergeAlpha function

[Lars Strojny]

No objection from my POV. Going to merge it in around a week, if no one objects.

Am 02.01.2013 um 10:35 schrieb matt clegg :

> I have added ImageCopyMergeAlpha as an extra function to resolve bug 23815.
> 
> I have created a pull request on github
> https://github.com/php/php-src/pull/211
> 
> Can this be merged into 5.5? And, what do I need to do?
> 
> -- 
> 
> 
> Matt Clegg
> 
> --http://mattclegg.com/


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

Re: [PHP-DEV] [RFC] zend_parse_parameters() improvements

[Lars Strojny]

The is_null feature is really helpful. Thanks!

Am 02.01.2013 um 16:26 schrieb Johannes Schlüter :

> 
> 
> Gustavo Lopes  wrote:
>> I've written an RFC. It's available on:
>> 
>> 
> 
> The patch is mssing an update to README.PARAMETER_PARSING and if you ant to 
> truly export zend_parse_parameter() please mark it as ZENDAPI so it's 
> available from shared extensions and such.
> 
> johannes
> 
> 
> 
> -- 
> 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] DateTime improvement

[Lars Strojny]

Hi Derick,

I would go with DateTimeValue or DateTimeImmutable as well.

Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei :

> On Mon, Dec 17, 2012 at 5:48 PM, Derick Rethans  wrote:
> I went for DateTimePoint. Point as in "Point in time". I am not too
> happy with the name, but I think it works better than DateTimeImmutable
> as that just sounds quircky. I'm still fixing up a few things and adding
> some test cases. I think I need to make it work with DatePeriod too -
> but I haven't looked at that yet.
>  
> some suggestions:
> 
> DateTimeValue
> DateTimeImmutable
> DateImmutable
> DateFixed
> DateStatic
> (and as a bonus: DateTime2)


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

Re: [PHP-DEV] DateTime improvement

[Lars Strojny]

This is so cool, thanks Derick! If you need help with testing or anything else, 
let me know.

Am 16.12.2012 um 13:21 schrieb Derick Rethans :

> On Tue, 11 Dec 2012, Derick Rethans wrote:
> 
>> On Mon, 10 Dec 2012, Herman Radtke wrote:
>> 
>>> Another option is to make an ImmutableDateTime class. The DateTime
>>> class could actually be changed to inherit the ImmutableDateTime
>>> class. The only extensions on the DateTime class would be the mutable
>>> methods.
>> 
>> I'm not really against that, but we do need to use the Date namespace - 
>> so DateTimeImmutable. It might be trickier to do than it sounds 
>> though...
> 
> I've started hacking on this - with some luck I'm done before PHP 5.5 
> beta1.
> 
> cheers,
> Derick
> 
> -- 
> 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] Core liason for PHP FIG

[Lars Strojny]

Hi Pierre,

Am 16.12.2012 um 13:08 schrieb Pierre Joye :

> This is something we have seen in the past, "legacy" core developers
> were not really in sync with the community needs or wishes. That's why
> we need them to work with the core instead of the other way 'round. It
> will create more bridges between FIG, the various leading PHP projects
> and the language development and design.

I couldn’t agree more, this is and was a problem. Still, the modus operandi of 
PHP FIG is "people representing projects" and I don’t see any core developers 
participating there (which is obviously nobodies fault). If nobody else is 
interested, would anybody object me representing core at PHP FIG?

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

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

[Lars Strojny]

Hi Kris,

thanks for your response. Just a short note: I'm not in any ways officially 
related to PHP FIG, except that I find it personally to be a good initiative. 
Rest of the answers below.

Am 16.12.2012 um 11:50 schrieb Kris Craig :

> My one concern with this idea is that it could give the erroneous impression 
> that the coding style standards your group advocates are endorsed, implicitly 
> or otherwise, by the PHP Group.  There is no "official" standard when it 
> comes to spaces vs. tabs and whether to place brackets on the same line, for 
> example.  Given how many different competing standards there are out there, I 
> fear that we could run the risk of showing favoritism by "legitimizing" one 
> standards group but not others.

I see what you mean. On the other hand though, a majority of important PHP 
projects are organized there. We (as core developers) can’t ignore what these 
projects are discussing and I don't think we should. And if we have a saying in 
that, why shouldn’t we endorse such an initiative.

> Personally, and I'm just speaking for myself here, I think you guys 
> over-reached with your PSR-2 style guidelines.  I totally agree with your 
> goal of aiding consistency, but these standards are inherently arbitrary and 
> it makes me very uneasy to see anyone proclaim that such-and-such is the 
> "correct" style of doing something in PHP.  The only solution I can see is to 
> create several different style rulesets to reflect all the noteworthy styles 
> in popular use.  Of course, then you run the risk of undermining the whole 
> consistency goal.

I, again, can’t speak for PHP FIG, but it seems to me like the survey technique 
worked out pretty well. So PSR-1 and PSR-2 are what most projects are doing 
anyway.

> I wouldn't be adverse to us linking to your project, so long as we do the 
> same for any others that crop-up and we make it clear that these third-party 
> standards are not officially endorsed by the PHP Group.  I also think it's 
> cool if anyone here wants to join your project and contribute, so long as 
> that person is representing him/her self.

See point above. We can’t ignore what major players in the ecosystem do and I 
don't think we should. I would much rather see PHP core have a saying in their 
decisions than standing by the lines and letting things happen (which might 
even be counter-productive for core).

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

[PHP-DEV] Core liason for PHP FIG

[Lars Strojny]

Hello everybody,

for all of you who don’t know, PHP FIG (Framework Interoperability Group, 
http://www.php-fig.org/) discusses ways frameworks and libraries can work 
together and integrate much easier. Current PSRs are PSR-0 to standardize 
autoloading, PSR-1 and PSR-2 that deal with coding styles. All three are great 
initiatives so far in bridging gaps between projects and making the PHP 
ecosystem, well, rounder.

PHP core currently doesn’t have a vote in that group and I think this is 
something we should change. Is anybody interested in taking part of the 
discussions there and representing PHP core?

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

Re: [PHP-DEV] [RFC] Modify tempnam() to handle directories and auto-cleanup

[Lars Strojny]

Good idea!

Am 26.11.2012 um 22:21 schrieb Sara Golemon :

> https://wiki.php.net/rfc/request-tempnam
> 
> Just a bit of hand-holding for those who don't remember to clean up
> their messes.
> 
> -- 
> 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] Generics proposal

[Lars Strojny]

Cool! Looking forward to it.

Am 07.11.2012 um 06:41 schrieb Sara Golemon :

> Retrying this with reply-to-all. :)
> 
> I think it's an awesome moment for PHP and HipHop to work together! :)
> I'll summarize what we have so far into an RFC.
> 
> -Sara
> 
> On Tue, Nov 6, 2012 at 12:50 PM, Lars Strojny  wrote:
>> Hey Sara,
>> 
>> can you already show us how your take on Generics would look like? Maybe 
>> this is a good moment for HipHop and PHP to do something together.
>> 
>> Am 06.11.2012 um 04:14 schrieb Sara Golemon :
>> 
>>> Sorry to be late to the conversation, but fwiw, HipHop is adding
>>> Generics (and some other cool things) to our PHP implementation.  We
>>> plan to provide a PHP equivalent implementation in the form of a
>>> pre-processor extension which can live in PECL.  The implementation
>>> would of course be cleaner if done directly in the engine, but with
>>> APC the performance hit of doing an extra transformation pass should
>>> disappear. Hopefully this satisfies both the want for Java/C++-like
>>> syntax without "polluting" the language.
>>> 
>>> -Sara
>>> 
>>> On Tue, Oct 23, 2012 at 4:21 AM, Etienne Kneuss  wrote:
>>>> Hi,
>>>> 
>>>> On Tue, Oct 23, 2012 at 4:17 AM, Levi Morrison  
>>>> wrote:
>>>>>>> Especially if the ability was afforded to arrays as well (function
>>>>>>> foo(array $array){})...
>>>>>> 
>>>>>> This would require O(n) runtime tests, I would definitely not go there.
>>>>> 
>>>>> Actually, it does not require O(n) runtime tests.  The solution is
>>>>> simple: store the type when it is created. Whenever an element is
>>>>> added, make sure it matches the correct type.  All this does is add
>>>>> some flat overhead.
>>>> 
>>>> If you test every time you add one element, that's still O(n) tests
>>>> where n is the size of the array, the only benefit is that it is not
>>>> checked for each calls to a function. But now we are talking about
>>>> attaching non-trivial types to variables, and non-trivial checks in a
>>>> lot of places (think references etc..), let's not go there...
>>>> 
>>>>> 
>>>>> I am also supportive of the idea of having generics, but I am not sure
>>>>> that the work it would take is worth it.
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Etienne Kneuss
>>>> http://www.colder.ch
>>>> 
>>>> --
>>>> 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
> 


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

Re: [PHP-DEV] Generics proposal

[Lars Strojny]

Hey Sara,

can you already show us how your take on Generics would look like? Maybe this 
is a good moment for HipHop and PHP to do something together.

Am 06.11.2012 um 04:14 schrieb Sara Golemon :

> Sorry to be late to the conversation, but fwiw, HipHop is adding
> Generics (and some other cool things) to our PHP implementation.  We
> plan to provide a PHP equivalent implementation in the form of a
> pre-processor extension which can live in PECL.  The implementation
> would of course be cleaner if done directly in the engine, but with
> APC the performance hit of doing an extra transformation pass should
> disappear. Hopefully this satisfies both the want for Java/C++-like
> syntax without "polluting" the language.
> 
> -Sara
> 
> On Tue, Oct 23, 2012 at 4:21 AM, Etienne Kneuss  wrote:
>> Hi,
>> 
>> On Tue, Oct 23, 2012 at 4:17 AM, Levi Morrison  
>> wrote:
> Especially if the ability was afforded to arrays as well (function
> foo(array $array){})...
 
 This would require O(n) runtime tests, I would definitely not go there.
>>> 
>>> Actually, it does not require O(n) runtime tests.  The solution is
>>> simple: store the type when it is created. Whenever an element is
>>> added, make sure it matches the correct type.  All this does is add
>>> some flat overhead.
>> 
>> If you test every time you add one element, that's still O(n) tests
>> where n is the size of the array, the only benefit is that it is not
>> checked for each calls to a function. But now we are talking about
>> attaching non-trivial types to variables, and non-trivial checks in a
>> lot of places (think references etc..), let's not go there...
>> 
>>> 
>>> I am also supportive of the idea of having generics, but I am not sure
>>> that the work it would take is worth it.
>> 
>> 
>> 
>> --
>> Etienne Kneuss
>> http://www.colder.ch
>> 
>> --
>> 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] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

[Lars Strojny]

Hi Stas, hi Etienne,

let’s get practical and apply LSP to property accessors. Find below what I 
would read from the characteristics of LSP.

Am 31.10.2012 um 20:46 schrieb Stas Malyshev :
[...]
>> Instead, LSP simply states that, given B <: A, all objects of A can be
>> substituted by objects of B while preserving the validity of the
>> method calls on these objects, and the validity of their return
>> values. This is guaranteed here:



Characteristics 1: Contravariance of method arguments in subtypes

This applies to properties in so forth, that weaker requirements need to be 
allowed. This means:

  - Redeclaring a property without a specific type is OK (e.g. parent DateTime, 
children everything)
  - Redeclaring a property with a supertype is OK (e.g. parent MyDateTime, 
children DateTime)
  - Redeclaring a property that was read only as read-writable is OK in theory 
(it isn’t because of the history rule)
  - Redeclaring a property with as less visible is not OK (parent public, 
children protected)
  - Redeclaring a property with as more visible is OK (parent protected, 
children public)
  - Redeclaring a property as read-only is not OK (parent rw, children ro)

Characteristics 2: Covariance of method return values in subtypes

  - For properties, this basically mirrors the rules from rules from 
characteristics 1

Characteristics 3: Preconditions cannot be strengthened: This is something we 
cannot and should not prevent in the language itself but it’s up to the 
programmer to do this correctly
Characteristics 4: Postconditions cannot be weakened: See 3
Characterestics 5: History rule. See 3

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

Re: [PHP-DEV] PR 186: external protocols and locale independent string conversion

[Lars Strojny]

Hi,

thanks for bringing this up again. I digged even deeper into the whole issue of 
converting floats to strings and my current findings are that we can’t solve 
that consistently as things are already fubar’ed. The reason for that is, that 
in order to solve this issue we would need to make everything locale 
independent except output functions. Problem is: it’s a thin line. printf("%s", 
1.2) is locale aware, echo is as well. But then, should sprintf() be locale 
aware as well? What about the parameter parsing API (e.g. strpos(1.2, ".") will 
fail with de_DE as a locale). So: let’s ease the pain where possible, fix 
things that pop up step by step but I don’t see "the grand solution"[tm] for 
this problem.

Am 27.10.2012 um 16:33 schrieb Stas Malyshev :
[...]
> I'd suggest talking directly to PGSQL maintainers... In general, the
> pull seems to be fine to me, but I'd rather have the people that
> understand something in PGSQL APIs look at it :)

I agree with this one. For me, the PR looks fine and it would ease some pain.

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

Re: [PHP-DEV] Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST

[Lars Strojny]

Hi,

Am 25.10.2012 um 07:03 schrieb JJ :
[...]
> My solution was to check the type for CURLOPT_SSL_VERIFYHOST: if it is
> boolean and true, the opt value for libcurl is set to 2L.
> 
> I understand that engineers should have the proper option value to
> begin with but weighing the impact of this (MITM attacks) against
> doing what they probably meant anyways is worth the presumption.
> 
> Please discuss and adjust the patch if necessary.

Good find. I would suggest to not actually change the behavior but throw a 
warning when a boolean is passed and advise the user to either pass int(1) 
explicitly or use int(2). Link to the manual in the warning and be good.

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

Re: [PHP-DEV] Generics proposal

[Lars Strojny]

Hi Rasmus,

Am 20.10.2012 um 23:02 schrieb Rasmus Lerdorf :
[...]
> Personally I would hate to see this anywhere near PHP.

Do you mind explaining the why? Isn’t it better than new 
Collection("TypeAsAString") and custom assertions in each and every method of 
that collection class?

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

Re: [PHP-DEV] PR 186: external protocols and locale independent string conversion

[Lars Strojny]

Hi,

Am 19.09.2012 um 20:35 schrieb Lars Strojny :
[...]
> This kind of fix is very likely needed in other places, where floats are 
> converted using convert_to_string(). I haven’t found time to try e.g. 
> mysqlnd, but I suspect we’ll find similar issues there. I don’t think the 
> proposed workaround of burden users with explicitly converting floats to a 
> numeric representation is a good solution and I think we should fix bugs like 
> that in places they occur.

[...]

Quick follow-up, PDO::quote() and mysqli::real_escape_string() suffer from the 
same issue.

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

[PHP-DEV] PR 186: external protocols and locale independent string conversion

[Lars Strojny]

Hi everybody,

I'm currently working on https://github.com/php/php-src/pull/186, which fixes a 
problem with PostgreSQL when passing a float to pg_query_params() with a locale 
setting that uses "," as a decimal point. pg_query_params() uses 
convert_to_string(), which uses %G as a format string for floats, which is 
locale sensitive (and therefore converts e.g. in hr_HR or de_DE to "1,1"). The 
proposed fix is to introduce a new API convert_to_cstring() in the Zend Engine 
to allow converting types to C-locale strings.

This kind of fix is very likely needed in other places, where floats are 
converted using convert_to_string(). I haven’t found time to try e.g. mysqlnd, 
but I suspect we’ll find similar issues there. I don’t think the proposed 
workaround of burden users with explicitly converting floats to a numeric 
representation is a good solution and I think we should fix bugs like that in 
places they occur.

What’s your take on the proposed fix of introducing convert_to_cstring() and 
using it where external protocols require a locale insensitive float conversion?

cu,
Lars
--
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

[Lars Strojny]

Hi,

Am 19.09.2012 um 18:11 schrieb Michael Stowe :

> Personally, I would like to see it operate similar to MySQLi, where you
> have the convenience of OOP, but can still call a function directly in a
> procedural manner.

There seems to be a need for a procedural API. As their is one, let’s do it 
similar to how MySQLi etc. does it and use a context resource:

$ctx = escape_context_create('UTF-8');
$str = escape_html_attr($ctx, $str);

And so on. 

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

Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars

[Lars Strojny]

Hi,

Am 13.09.2012 um 16:02 schrieb Marco Pivetta :

> I don't think autoloading is needed here, since the FQCN can be resolved
> without it (exactly like with type hinting).

Has nothing to do with autoloading. It only checks if there is a use statement. 
Auto-loading is triggered during call time, not during compile time.

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

Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars

[Lars Strojny]

Hi Dmitry,

Am 13.09.2012 um 11:12 schrieb Dmitry Stogov :

> We already have isset(), empty(), unset() that are a special purpose 
> functions handled by compiler.
[...]

That’s exactly my point: these special purpose functions present themself to 
the user as usual functions and set a certain expectation. That’s why we now 
allow empty(func()). If something presents itself as a syntax element, there is 
no such expectation and the only valid software metric, WTFs per minute 
decreases slightly.

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

Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars

[Lars Strojny]

Hi Simon,

Am 13.09.2012 um 10:34 schrieb Simon J Welsh :
[...]
> I would expect $variable::class to work (like late static bindings). 
[...]

Than better try the patch, as it doesn’t work now :)

But it is a good point indeed. @Ralph: what do you think?

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

Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars

[Lars Strojny]

Hi Dmitry,

Am 13.09.2012 um 10:17 schrieb Dmitry Stogov :
[...]
> I think the syntax is wired.
> Instead of classname::class I would prefer something like class(classname).

Wouldn’t this look too much like a function with all the implications that 
might cause like users expecting class($variable) to work or even 
class(otherfunc())?

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

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

[Lars Strojny]

Hi,

Am 09.09.2012 um 13:52 schrieb Johannes Schlüter :
[...]
> 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.

Or put it that way: if you need a specific order, sort it "by code".

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

Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword

[Lars Strojny]

Hi Ralph,

Am 08.09.2012 um 20:03 schrieb Ralph Schindler :
[...]
>> What I find absolutely confusing is the use of Class vs. CLASS vs. class for 
>> constant names. Let’s limit the translation to FQCN.
> 
> I will clean up the proposal make the examples more consistent (all lower 
> case).  It's worth noting though, that this is reusing the reserved keyword 
> "class" which is case insensitive, so like you class declaration, any casing 
> will work.

Is see, looks like I misunderstood that part of the proposal as I though you 
were planning different behavior for different casing.

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

Re: [PHP-DEV] Easing major version upgrades

[Lars Strojny]

Hi Pierre,

Am 08.09.2012 um 20:23 schrieb Pierre Joye :
[...]
> 
>> 3.) Upgrades are hard, let’s go shopping aka never change a running system
> 
> What do you mean here?

A general reluctance to change production systems because "they work". But as I 
said, not our problem.

[...]

> No chance to achieve that with the current resources. Simply impossible.

That depends on what duties the internals developer define for themselves. If 
it is to run test suites of the top X extensions and document the outcome it 
totally sounds possible. It could even be part of a continuous integration 
process. For me it is not so much about more work, but about more transparency 
(e.g. the memcache extension and 5.4, only thing missing was a PECL release). 
Again, the proposal, a little more concise:

  - Find out about top X extensions
  - Define their compatibility as blocking for a new release (as an adjustment 
to the release process)
  - Maintain a status page and the related bugs
  - Publish the current compatibility status so that people know

The alternative to not fixing this problem is an increasing gap between what we 
think people should use in production and what they actually use and expect us 
to maintain. Additionally fixing compatibility issues is usually a good 
starting point for new talent.

[...]

> About APC, yes, I definitively would like to get an opcode cache only
> version of APC, with very few or almost no ini setting, no user cache,
> cleaned from all these esoteric ( 0.01% of the users using them), etc.
> But that's a different topic :)

That’s indeed a different topic but it would ease a lot of pain to have a fully 
compatible APC from day one.

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

Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword

[Lars Strojny]

Hi Ralph,

I still like the proposal.

Am 08.09.2012 um 07:12 schrieb Ralph Schindler :
[...]
>>> But yes, I agree that runtime resolution only duplicates existing
>>> behavior, so it isn't really necessary (you could argue thought that
>>> self::class similarly also only replicates the existing __CLASS__). It
>>> would be nice for consistency in my eyes, but I'm good without it too
> 
> The current patch allows for the following:
> 
>  self::class -> resolves to name in active_class_entry
>  static::class -> resolves to FCALL get_called_class()
>  parent::class -> resolves to FCALL get_parent_class()
> 
> I would have liked to have done parent::class w/o FCALL but the 
> active_class_entry's parent is empty even when inside of a class extending 
> another class.
> 
[...]

What I find absolutely confusing is the use of Class vs. CLASS vs. class for 
constant names. Let’s limit the translation to FQCN.

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

[PHP-DEV] Easing major version upgrades

[Lars Strojny]

Hi everybody,

with the release of PHP 5.4 a similar pattern happened as with the release of 
5.3: while we want people to upgrade as fast as possible, it is often a bumpy 
road for users to migrate to new versions. There are various reasons for it: 

1.) Incompatible and hard to change codebases that won’t run on newer PHP 
versions
2.) Distributions slowly providing packages for new major versions
3.) Upgrades are hard, let’s go shopping aka never change a running system
4.) Popular and/or simply required extensions like memcache, apc, etc. aren’t 
prime-time ready for the new version

While point one to three are merely a point we can campaign for (or against), 
point four is something we can do better. Two anecdotes about the current state 
of PHP 5.4 and popular extensions: we don’t have a (released) PHP 5.4 
compatible version of the memcache extension and APC is still not ready for all 
of our users (including myself) but it is practically required for production 
setups. So we are six month into 5.4 but the perceived 5.4.0 is still due for a 
number of people. And this is something we should do better.

There are various ways how to handle that situation: the "broaden the core" 
initiative is one of them (and bundling a stripped down version of APC is 
surely a good idea) but I would like to propose a simpler solution: we find out 
by a yet to be exactly determined combination of community survey and data 
analysis which PECL extensions are the most popular ones and make sure that the 
top X of them is ready when release 0 of a new major version is released. And 
we define this as a required part of our  release process. If the most popular 
extensions aren’t compatible, the version 0 of a major release cannot ship.

I'm not suggesting this will make everything nice and shiny but it will 
certainly ease the pain for our users.

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

Re: [PHP-DEV] RFC for Adding __toString to DateTime

[Lars Strojny]

Hi Will,

Am 03.09.2012 um 15:04 schrieb Will Fitch :
[...]
> 
> 
> Hi, Lester - I'll update the patch and RFC to include this format.  This is
> the format I'll use unless others have a better approach:
> 
> 2012-09-01T00:00:00-0500 (America/Chicago)

Psst ... microseconds ... pssst. Please include them.

cu,
Lars

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

Re: [PHP-DEV] RFC for Adding __toString to DateTime

[Lars Strojny]

Hi Will,

Am 03.09.2012 um 14:01 schrieb Will Fitch :

> On Mon, Sep 3, 2012 at 7:57 AM, Pierre Joye  wrote:
[...]
> I actually feel a static function which tracks globally would best serve
> this case:
> 
> date_default_format_set('c')
> 
> This would prevent the need for setting it on a per instance basis -
> similar to the way timezones can be set:
> 
> date_default_timezone_set('America/Chicago')


Please let’s not add another global setting. DateTime objects are basically 
value objects. If you need to create specific flavors of them, use a Factory.
Otherwise we will end up with horrible incompatibilities between libraries 
depending on different formats.

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

Re: [PHP-DEV] RFC for Adding __toString to DateTime

[Lars Strojny]

Hi Pierre, hi Will,

Am 03.09.2012 um 13:57 schrieb Pierre Joye :

> hi Will,
> 
> On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch  wrote:
>> On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue  wrote:
>> 
>>> As far as I can tell, there's no standard which uses the Olson database
>>> to specify the timezone, so we'd have to create one.
>>> 
>>> What about ISO8601 with the Olson timezone suffixed?
>>> 
>>>2012-09-02T18:17:36+0100 (Europe/London)
>>>2012-09-02T18:19:05+0100 (Africa/Niamey)
>>> 
[...]
> 
> I don't think you will ever get a consensus on that. The reason is
> that this case falls in the same fall than the timezone itself (but
> per instance of an object instead of globally).
> 
> I'd to suggest to force the definition of a format using the
> setStringFormat (or whatever will be the name of this function).
> __toString will then fail if no format has been set, warning and
> returns NULL (f.e.).


I don’t agree here, especially if we recap what the proposed purpose of the 
__toString() method was:

  Ease debugging by allowing "echo $date;" instead of "echo $date->format(...);"

An additional constraint to make sure users use it for debugging and nothing 
else, would be:

  Not allow changing the format, neither by ini setting or any other global 
means (incl. setters)

To achieve that, we need a time format that is best for debugging, meaning, as 
lossless as possible. While ISO8601 comes pretty close it misses out on the 
Olson timezone suffix. I would second the notion of creating our own format and 
standardizing it internally with it’s own constant and DateTime doing the right 
thing if passed to the constructor. Additionally to what Ryan proposed, 
microseconds should be part of it (which ISO allows). So, here we go:

  2012-09-02T18:17:36.12345+0100 (Europe/London)

Following this, the change would be fairly easy (adding a constant, a bit 
parsing fu and the toString() method).

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

Re: [PHP-DEV] A new php Validator and Filter interface for the SPL

[Lars Strojny]

Hi Axel,

I think PHP core is just not the place for such standardization, as long as 
those interface do not interact with the engine (as i.e. Traversable does). 
Different frameworks might or might not agree on various interoperability 
standards and that’s fine. Having those interfaces in core would bind the life- 
and deprecation cycles of interoperability agreements to the lifecycle of the 
language.

cu,
Lars

Am 31.08.2012 um 14:55 schrieb Axel Etcheverry :

> Hi, 
> 
> Please take a look at https://github.com/php/php-src/pull/180
> 
> This patch is designed to offer two new interfaces in the SPL to standardize 
> filters and validators of frameworks (ZF, SF, etc ...).
> 
> This allows the developer to use validators and filters of different sources 
> in a same application.
> 
> The tests are in the patch.
> 
> Comments and feedback welcome.
> 
> -- 
> Best regards,
> Axel Etcheverry
> 
> Phone : +33 6 84 15 57 52
> Twitter : @euskadi31 (http://twitter.com/euskadi31)
> Home : http://www.axel-etcheverry.com (http://www.axel-etcheverry.com/)
> Audiofanzine : http://fr.audiofanzine.com (http://fr.audiofanzine.com/)
> Auto-broc : http://www.auto-broc.fr (http://www.auto-broc.fr/)
> 
> 
> 


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

Re: [PHP-DEV] [VOTE]Call for voting: support use list in foreach

[Lars Strojny]

Am 27.08.2012 um 03:55 schrieb Rasmus Lerdorf :
[...]
> And we aren't just C89 anymore actually. We still try to stick to it
> when possible, but for example in the intl extension you will find C++
> and it won't build without it. The idea there is that any small embedded
> platform that may still only have C89 support is unlikely to link
> against the massive ICU library.
> 
> But we may be at the point where even tiny embedded platforms have
> better compiler support and we don't need to stick to C89 anymore.

If I understand Wikipedia (http://en.wikipedia.org/wiki/C99) correctly, C99 is 
not at all supported in MS Visual C++ (except non-standard extensions like 
__inline or __forceinline). So C99 might not be a good candidate for us just 
now. But I'm sure Pierre has more on that issue.

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

Re: [PHP-DEV] [VOTE]Call for voting: support use list in foreach

[Lars Strojny]

Hi Gwynne,

Am 27.08.2012 um 03:39 schrieb Gwynne Raskind :

> (And
> a side note on that, the requirement of C89 standard compliance in PHP
> has less and less advantage these days, and handicaps those few
> language features in the later flavors of C (C99, gnu99, Clang C,
> etc.) which -could- lessen the current unreadability of the code.)

OT but because I stumbled upon that some time ago: what was the original reason 
to enforce C89 and what would be needed to allow a modern standard?

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

Re: [PHP-DEV] Merging fix for quoted_printable_encode()

[Lars Strojny]

Hi everybody,

patch + test merged to master and 5.4. I would really like to merge it to 5.3 
as well but if others disagree I could live without it.

With regards,
Lars

Am 20.08.2012 um 22:03 schrieb Lars Strojny :

> Hi Stas,
> 
> I would prefer it int 5.3 as well as it might break mailing systems using 
> quoted_printable_encode(). I’ll add the test from the comments as well.
> 
> Am 20.08.2012 um 20:30 schrieb Stas Malyshev :
> 
>> Yes. For 5.3, it does not look like a critical bug, so it shouldn't be
>> there. Also, the tests are still not there - so they should be added
>> before the merge can happen.
> 
> 
> --
> 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] Merging fix for quoted_printable_encode()

[Lars Strojny]

Hi Stas,

I would prefer it int 5.3 as well as it might break mailing systems using 
quoted_printable_encode(). I’ll add the test from the comments as well.

Am 20.08.2012 um 20:30 schrieb Stas Malyshev :

> Yes. For 5.3, it does not look like a critical bug, so it shouldn't be
> there. Also, the tests are still not there - so they should be added
> before the merge can happen.


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

[PHP-DEV] Merging fix for quoted_printable_encode()

[Lars Strojny]

Hi everybody,

I would like to merge https://github.com/php/php-src/pull/120 in HEAD, 5_4 and 
5_3 to fix splitting of soft line breaks. Any concerns?

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

Re: [PHP-DEV] Support negative indexes for arrays and strings

[Lars Strojny]

Hi Marc,


Am 17.06.2012 um 21:53 schrieb Marc Easen:
[...]
> Numerical keyed array:
> 
>$a = array('foo', 'bar', 'baz');
>$a[0] === 'foo'
> 
> I would expect:
> 
>$a[-1] === 'baz';
> 
> An string keyed array:
> 
>$b = array('foo' => 1, 'bar' => 2, 'baz' => 3);
>$b[0] === 1;
> 
> Would generate an E_NOTICE:   PHP Notice:  Undefined offset: 0 in php shell 
> code on line 1.
> An negative offset would also generate the same E_NOTICE.
> 
> So going back to your point, the change would only be to numeric based arrays 
> (list) and strings. It could be possible to string keyed arrays to be 
> accessed by the numeric counter parts, but I'm not familiar to comment on if 
> this is even possible.

I see, must have overread that. This makes it slightly better but not optimal, 
as too varying behavior for hashes vs. lists will be harder to explain. We 
could go down that road and separate the both more and more but given the 
history (and the usage patterns) of arrays in PHP I'm not convinced this is a 
good idea.

I would prefer something like this (and no, I don't propose using ':' as an 
operator for real):

$string = "bar";
$string:-1   // "b"
$string:-2   // "r"
$string:-10   // NULL

$list = array("one", "two", "three");
$list:-1 // "three"
$list:-2 // "two"
$list:-10// NULL

$hash = array("one" => 1, "two" => 2, "three" => 3)
$hash:-1 // 3
$hash:-2 // 2
$hash:-10// 10

As using arrays as hashes let’s them behave in a FIFO kind of way, we can do 
proper slicing.

> It seems this topic has generated a lot of interest, I feel the best way to 
> proceed would be to write a RFC. I've never written one before so could 
> someone give me access to create a page on the RFC site or create a RFC for 
> me and give me permission to update it, my username is 'easen'.

For sure, RFC makes sense. I like the general idea, I’m just not sure about the 
syntax.

cu,
Lars

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [VOTE] Vote change for empty() RFC

[Lars Strojny]

Hi Rafael,

hope it’s ok I've reopened the vote temporarily, but you’ve got the missing 
vote.

Am 21.05.2012 um 01:05 schrieb Rafael Dohms:

> On Mon, May 21, 2012 at 12:44 AM, Pierre Joye  wrote:
>> 
>> 
>> See the previous mails, as long as other voters agree to change their
>> votes to empty only, we are done.
> 
> If my math does not fail me, we needed one more vote to have the 2/3 
> mentioned.
> Anthony has changed his vote, i think we are good to go.
> 
> 20 votes => 2/3 = 13.3
> 
> So if we round down, the vote originally passed, and in any case
> Anthony makes it 14, so that should resolve any doubts
> 
> Also, for future votes we need to make this rule clear: does 13.3 mean
> we need 13 votes or 14 votes to pass?
> In which case, this whole thread might actually have been for nothing
> since the vote had already passed.
> 
> -- 
> Rafael Dohms
> PHP Evangelist and Community Leader
> http://www.rafaeldohms.com.br
> http://www.phpsp.org.br
> 
> -- 
> 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] Internals books (c) 2007+ ?

[Lars Strojny]

Yep, that might be exactly the problem. The audience for such a book might be 
less than 100.

Am 17.05.2012 um 06:24 schrieb Sanford Whiteman:

>> Sara’s book is still the best we have, nevertheless it shows its
>> age. In Theo Schlossnagles "Scalable Internet Architectures" also
>> has a chapter on PHP internals. The rest is more or less reading
>> existing code and playing around. Looks like somebody on Internals should 
>> land a book deal :)
> 
> Thanks, Lars. I first learned about zvals from a chapter in George
> Schlossnagle's Advanced PHP Programming, so it seems like there are
> deeper dives here and there. I don't know about the book deal if I'm
> the only to ask about it in so long, though. :)
> 
> -- S.
> 
> 
> --
> 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] Internals books (c) 2007+ ?

[Lars Strojny]

Hi Sanford,

Sara’s book is still the best we have, nevertheless it shows its age. In Theo 
Schlossnagles "Scalable Internet Architectures" also has a chapter on PHP 
internals. The rest is more or less reading existing code and playing around. 
Looks like somebody on Internals should land a book deal :)

With regards,
Lars

Am 15.05.2012 um 07:00 schrieb Sanford Whiteman:

> Hi All,
> 
> Trying to ready myself for some possible work w/the core (after I
> resurrect all my never-that-great C, heh), I went looking for a recent
> book. (I still like old-school supplements.)
> 
> I see Sara's from 2006 on Amazon, but nothing after that under 'PHP
> internals'. I'm sure that one's not totally obsolete, but I don't know
> if programming styles and patterns have changed even if the bulk of
> the code has not. At the risk of fanning some flames I don't know
> about... is there a more recent book that's generally liked?
> 
> Thanks,
> 
> S.
> 
> 
> -- 
> 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 Feature: Fully qualified class name resolution as scalar with class keyword

[Lars Strojny]

Hi Ralph, hi everybody,

given the clear use case and the simplicity of the patch, a very good idea. 

With regards,
Lars

Am 15.04.2012 um 16:13 schrieb Ralph Schindler:

> 
>> I used to implement `public static function getClass() { return
>> get_called_class(); }`, so I really like this one, makes it also easier
>> for IDEs when refactoring code :)
> 
> Oh completely, that is one of the major benefits.  My current workflow for 
> refactoring is to refactor with the built-in support, but then also having to 
> go find/replace on the full class name, just in case.
> 
> -ralph
> 
> -- 
> 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] Multiple Visibility Level Getters/Setters

[Lars Strojny]

Just throw an error if conflicting accessors are defined. In the case of 
subtypes: accessors may broaden the interface, but not limit it => LSP. So it’s 
fine to make a parents protected accessor public, but not the other way around.

Am 19.11.2011 um 02:46 schrieb Clint M Priest:

> What would everyone think about multiple levels of visibility for 
> getters/setters?
> 
> class Sample {
> 
> public $Variable {
>public get { return "Public"; }
>protected get { return "Protected"; }
>private get { return "Private"; }
> 
>public set { ... }
>private set { ... }
> }
> }
> 
> Whichever getter/setter would be called with the most restricted access, so 
> externally public, internally protected (if inherited) or private from within.
> 
> Any value to this?  I can see some use cases and wouldn't be any more 
> difficult to implement into what I'm already doing.
> 
> -Clint


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

Re: [PHP-DEV] weak references

[Lars Strojny]

While I like SplWeekRef and the somewhat proposed SplWeekRefList, you’ll
find attached a patch that exposes a simple function „refcount“ having
this signature:

int refcount(mixed value)

So if you would like to play around with it, have fun. It would be
interesting to see if there are any other use cases besides destroying a
reference.

An idea for a userland implementation of SplWeekRefList with auto cleanup:
let SplWeekRefList register a ticket function which executes cleanup with
a certain propability. Something along the lines of this:

:

>Am 18.07.2011 10:15, schrieb Ferenc Kovacs:
>> I think that having to know and care about refcounts and zvals are
>> more complicated than having an Spl class, which can hold a reference
>> for a variable what can be destroyed to free memory.
>> and there is a chance that people are familiar with the Weak
>> references from other languages, while the zval approach only familiar
>> for those that knows about php internals.
>> so I think that from the userland POV, weak references are easier to
>>grasp.
>
>You're right for users who indeed have this problem. But I am worried
>about those users, which do not have the problem, but still have to know
>what WeakReferences are...but I should wait for the RFC.
>
>
>-- 
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php
>

Index: Zend/zend_builtin_functions.c
===
--- Zend/zend_builtin_functions.c   (revision 313122)
+++ Zend/zend_builtin_functions.c   (working copy)
@@ -94,6 +94,7 @@
 static ZEND_FUNCTION(gc_enabled);
 static ZEND_FUNCTION(gc_enable);
 static ZEND_FUNCTION(gc_disable);
+static ZEND_FUNCTION(refcount);
 
 /* {{{ arginfo */
 ZEND_BEGIN_ARG_INFO(arginfo_zend__void, 0)
@@ -237,6 +238,10 @@
 ZEND_BEGIN_ARG_INFO_EX(arginfo_extension_loaded, 0, 0, 1)
ZEND_ARG_INFO(0, extension_name)
 ZEND_END_ARG_INFO()
+
+ZEND_BEGIN_ARG_INFO_EX(arginfo_refcount, 0, 0, 0)
+   ZEND_ARG_INFO(0, object)
+ZEND_END_ARG_INFO()
 /* }}} */
 
 static const zend_function_entry builtin_functions[] = { /* {{{ */
@@ -306,6 +311,7 @@
ZEND_FE(gc_enabled, arginfo_zend__void)
ZEND_FE(gc_enable,  arginfo_zend__void)
ZEND_FE(gc_disable, arginfo_zend__void)
+   ZEND_FE(refcount,   arginfo_refcount)
{ NULL, NULL, NULL }
 };
 /* }}} */
@@ -385,6 +391,19 @@
 }
 /* }}} */
 
+/* {{{ proto int refcount(mixed value)
+   Returns the refcount for the passed object */
+ZEND_FUNCTION(refcount)
+{
+   zval *value;
+
+   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z", &value) == 
FAILURE) {
+   return;
+   }
+
+   RETURN_LONG(Z_REFCOUNT_P(value) - 1);
+}
+
 /* {{{ proto int func_num_args(void)
Get the number of arguments that were passed to the function */
 ZEND_FUNCTION(func_num_args)
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php