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 lisachenko...@gmail.com 
 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 p...@beccati.com 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 a...@ajf.me 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 p...@tutteli.ch 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 le...@php.net wrote:
[...]

 If these were split into separate files and autoloaded
 the current solution would work.
 
 ?php
 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 der...@php.net 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 a...@ajf.me 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 nikita@gmail.com 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 everyone,

On 24 Sep 2014, at 23:17, Rowan Collins rowan.coll...@gmail.com 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 N0 -
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] Little switch improvement: get the used variable

[Lars Strojny]

Hi Rowan,

On 26 Sep 2014, at 18:11, Rowan Collins rowan.coll...@gmail.com 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 N100 -
N ** foo(N-10);
 
 foo(N) when N0 -
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] [VOTE] Fix list() behavior inconsistency

[Lars Strojny]

Hi everyone,

On 25 Sep 2014, at 17:27, Patrick ALLAERT patrickalla...@php.net 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] 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 krak...@php.net:

 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] RFC: Anonymous Classes

[Lars Strojny]

Hi Joe,


Am 23.09.2013 um 19:22 schrieb Joe Watkins krak...@php.net:
[...]
  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] Argument unpacking - Multiple unpacks and trailing arguments

[Lars Strojny]

Hi Nikita,

Am 23.09.2013 um 21:33 schrieb Nikita Popov nikita@gmail.com:
[...]
 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] 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 yohg...@ohgaki.net:

 Hi David,
 
 On Fri, Aug 23, 2013 at 12:03 PM, David Muir davidkm...@gmail.com 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] 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 nikita@gmail.com:
[]
 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] [RFC] Constant Scalar Expressions

[Lars Strojny]

Super cool, thanks!

Am 13.08.2013 um 18:12 schrieb Anthony Ferrara ircmax...@gmail.com:

 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 se...@fb.com:

 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 se...@fb.com:

 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 Type though, but that's just a minor detail.

cu,
Lars

Am 25.06.2013 um 17:57 schrieb Anthony Ferrara ircmax...@gmail.com:

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

 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 tyr...@gmail.com:
[...]
 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] 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 jpa...@php.net:
[...]

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] property de-referencing

[Lars Strojny]

Hi Rasmus,

Am 25.04.2013 um 14:47 schrieb Rasmus Schultz ras...@mindplay.dk:
[...]
 
 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] DateTimeImmutable

[Lars Strojny]

Hi Derick,

Am 27.03.2013 um 21:53 schrieb Derick Rethans der...@php.net:

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

 2013.03.26. 20:29, Michael Wallner m...@php.net 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] 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 s...@mujo.be:

 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] 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 morrison.l...@gmail.com:

 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 sebast...@php.net:

 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 z...@zend.com:

 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 z...@zend.com:

 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 bobw...@hotmail.com:
[...]
 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] [RFC] Allow trailing comma in function call argument lists

[Lars Strojny]

Hi,

Am 20.02.2013 um 06:24 schrieb Laruence larue...@php.net:

 On Tue, Feb 19, 2013 at 8:06 PM, Sara Golemon poll...@php.net 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] 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 der...@php.net:

 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 z...@zend.com
 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 the latest 

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

[Lars Strojny]

Hi Marcello,

Am 19.02.2013 um 14:51 schrieb Marcello Duarte mdua...@inviqa.com:

 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 Julien,

Am 15.02.2013 um 13:05 schrieb Julien Pauli jpa...@php.net:

 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] 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 dso...@gmx.net:

[...]

 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] Status of pull request

[Lars Strojny]

Hi Jason,

thanks for the reminder.

Am 13.02.2013 um 14:03 schrieb Jason Gerfen jason.ger...@gmail.com:

 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

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 johan...@schlueters.de:

 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=0limit=30order_by=iddirection=DESCcmd=displaystatus=Openbug_age=0bug_updated=0bug_type=Allpatch=Ypull=Y
 Search for recent bugs with pull requests only:
 https://bugs.php.net/search.php?boolean=0limit=30order_by=iddirection=DESCcmd=displaystatus=Openbug_age=0bug_updated=0bug_type=Allpull=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

[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 ras...@lerdorf.com:

 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 a...@kazik.de:

 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] Bug #23815: Added extra ImageCopyMergeAlpha function

[Lars Strojny]

Any news?

Am 04.01.2013 um 13:45 schrieb Pierre Joye pierre@gmail.com:

 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 l...@strojny.net 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 cleggm...@gmail.com:
 
 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]

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

 On Sat, Jan 12, 2013 at 12:04 AM, Levi Morrison morrison.l...@gmail.com 
 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] [VOTE] array_column() function

[Lars Strojny]

Hi Ben,

Am 14.01.2013 um 23:16 schrieb Pierre Joye pierre@gmail.com:
[...]
 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]

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 glo...@nebm.ist.utl.pt:

 On Mon, 14 Jan 2013 23:16:52 +0100, Pierre Joye pierre@gmail.com wrote:
 
 On Mon, Jan 14, 2013 at 11:01 PM, Ben Ramsey ram...@php.net 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 12.01.2013 um 01:17 schrieb Ben Ramsey ram...@php.net:

 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 smalys...@sugarcrm.com:

 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] Fixing insecure cURL file uploading

[Lars Strojny]

Hi Stas,

Am 06.01.2013 um 06:38 schrieb Stas Malyshev smalys...@sugarcrm.com:
[...]
 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] [RFC] Reflection annotations reader

[Lars Strojny]

Hi Yahav,

Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar g.b.ya...@gmail.com:
[...]
 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] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

[Lars Strojny]

Hi Clint,

Am 04.01.2013 um 04:13 schrieb Clint Priest cpri...@zerocue.com:
[...]
   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] [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 cpri...@zerocue.com:

 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] [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 johan...@schlueters.de:

 
 
 Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
 I've written an RFC. It's available on:
 
 https://wiki.php.net/rfc/zpp_improv
 
 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] 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 cleggm...@gmail.com:

 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] 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 kont...@beberlei.de:

 On Mon, Dec 17, 2012 at 5:48 PM, Derick Rethans der...@php.net 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

[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] 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 kris.cr...@gmail.com:

 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

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

[Lars Strojny]

Hi Pierre,

Am 16.12.2012 um 13:08 schrieb Pierre Joye pierre@gmail.com:

 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] 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 der...@php.net:

 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] [RFC] Modify tempnam() to handle directories and auto-cleanup

[Lars Strojny]

Good idea!

Am 26.11.2012 um 22:21 schrieb Sara Golemon poll...@php.net:

 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 poll...@php.net:

 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 l...@strojny.net 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 poll...@php.net:
 
 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 col...@php.net wrote:
 Hi,
 
 On Tue, Oct 23, 2012 at 4:17 AM, Levi Morrison morrison.l...@gmail.com 
 wrote:
 Especially if the ability was afforded to arrays as well (function
 foo(arrayBar $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 poll...@php.net:

 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 col...@php.net wrote:
 Hi,
 
 On Tue, Oct 23, 2012 at 4:17 AM, Levi Morrison morrison.l...@gmail.com 
 wrote:
 Especially if the ability was afforded to arrays as well (function
 foo(arrayBar $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 smalys...@sugarcrm.com:
[...]
 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 smalys...@sugarcrm.com:
[...]
 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 ja...@php.net:
[...]
 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 ras...@lerdorf.com:
[...]
 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] RFC: Implementing a core anti-XSS escaping class

[Lars Strojny]

Hi,

Am 19.09.2012 um 18:11 schrieb Michael Stowe m...@mikestowe.com:

 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

[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] PR 186: external protocols and locale independent string conversion

[Lars Strojny]

Hi,

Am 19.09.2012 um 20:35 schrieb Lars Strojny l...@strojny.net:
[...]
 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

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 dmi...@zend.com:
[...]
 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] [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 si...@simon.geek.nz:
[...]
 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 11:12 schrieb Dmitry Stogov dmi...@zend.com:

 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,

Am 13.09.2012 um 16:02 schrieb Marco Pivetta ocram...@gmail.com:

 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] get_class_vars() returned information ORDER

[Lars Strojny]

Hi,

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

[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] 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 ra...@ralphschindler.com:
[...]
 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

Re: [PHP-DEV] Easing major version upgrades

[Lars Strojny]

Hi Pierre,

Am 08.09.2012 um 20:23 schrieb Pierre Joye pierre@gmail.com:
[...]
 
 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,

Am 08.09.2012 um 20:03 schrieb Ralph Schindler ra...@ralphschindler.com:
[...]
 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] RFC for Adding __toString to DateTime

[Lars Strojny]

Hi Pierre, hi Will,

Am 03.09.2012 um 13:57 schrieb Pierre Joye pierre@gmail.com:

 hi Will,
 
 On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wfi...@meetme.com wrote:
 On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue li...@rotorised.com 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] RFC for Adding __toString to DateTime

[Lars Strojny]

Hi Will,

Am 03.09.2012 um 14:01 schrieb Will Fitch wfi...@meetme.com:

 On Mon, Sep 3, 2012 at 7:57 AM, Pierre Joye pierre@gmail.com 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 Will,

Am 03.09.2012 um 15:04 schrieb Will Fitch willfi...@php.net:
[...]
 
 
 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] [VOTE]Call for voting: support use list in foreach

[Lars Strojny]

Hi Gwynne,

Am 27.08.2012 um 03:39 schrieb Gwynne Raskind gwy...@darkrainfall.org:

 (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] [VOTE]Call for voting: support use list in foreach

[Lars Strojny]

Am 27.08.2012 um 03:55 schrieb Rasmus Lerdorf ras...@lerdorf.com:
[...]
 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

[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] 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 smalys...@sugarcrm.com:

 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

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 l...@strojny.net:

 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 smalys...@sugarcrm.com:
 
 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] 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 pierre@gmail.com 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:

?php
declare(ticks=1);

class WeekRefList extends SplObjectStorage
{
public function __construct()
{
register_tick_function(array($this, 'cleanup'));
}

public function cleanup()
{
if (rand(1, 10) === 1) {
foreach ($this as $entry) {
// First ref is in ObjectStorage, second is $entry var
if (refcount($entry) === 2) {
unset($this[$entry]);
}
}
}
}
}



With regards,

Lars

Am 18.07.11 10:28 schrieb Lars Schultz unter lars.schu...@toolpark.com:

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

Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))

[Lars Strojny]

Very good find of an inconsistency. Does the testsuite reveal something
strange with that patch?

Am 10.07.11 19:41 schrieb Nikita Popov unter nikita@googlemail.com:

Well, I generally think that PHP should be less strict about reserved
keywords. The number
of reserved keywords increases with every further release of PHP. For
example PHP 5.4
introduces trait and insteadof. PHP 5.3 introduced even more. Every
new
keyword PHP
introduces both breaks old code and reduces the naming possibilities for
classes and methods.

I don't think that it's possible to refrain from adding further keywords.
The language grows and
with it the list of keywords.

But I do think that it should be possible to prevent these additions from
breaking old code or
restricting userland naming.

E.g. Writing

class Evaluator {
public function eval() {

}
}

Does in no way create an ambiguity with the eval language construct PHP
implements.

But still PHP doesn't allow writing the above code. It would make sense to
allow the
use of the keyword in such situations. Actually PHP already does this in
one
place:
The token after T_OPJECT_OPERATOR is never interpreted as a keyword. I.e.
one can
write $this-eval() (and define a magic __call method for 'eval').

I don't know whether this is actually possible, but I've at least already
seen a patch
(http://pear.php.net/~greg/smarter_lexer.patch.txt) for the methodname
case
linked
from a feature request (https://bugs.php.net/bug.php?id=28261).

MfG Nikita



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