Re: [PHP-DEV] [RFC] [Discussion] Retry functionality

[Mike Willbanks]

>
> Hello internals!
>
> The RFC that proposes adding retry functionality to the
> `try/catch/finally` block is now officially "under discussion".
>

This feature seems like something that would be extremely useful.  However,
the proposed syntax for the number of retries for a block level seems to
get me.  I think what might actually be better from a functional standpoint
is:

try {
  doSomething()
} catch (SomethingException $e) {
  retry 3;
} catch (RetryMaximumExceeded $e) {
  $e->getOriginatingException();
}

Forcing retry to only work on the keyword level and then providing a
distinct exception when the retry has been exceeded.  The issue obviously
with the above is that you would need to be able to add the originating
exception to it rather than bubbling up.  What I like more about this, is
that it makes it far more clear as per the rejected path and allows you to
determine that you had to throw since the retries failed so many times.
Often in many applications, you might retry a couple of times and then
defer that action to be handled in the background at a later time.  In
addition, you may also still want to handle that exception to check certain
criteria around the failure.  For instance, it is often that libraries
reuse the same exception but providing different codes and/or messages that
you may want to check to see if it is retryable or add additional meta data
to the response.

I also think that the RFC should state that retry keyword MUST be used with
a numeric number to prevent continuous loops.  Eventually all loops must
die and preventing this early on seems to be something that would be a good
idea to handle.


>
> https://wiki.php.net/rfc/retry-keyword
>
> Voting will open on Monday, July 3rd, 2017 @ 9 am CDT.
>
> Voting will close on Monday, July 17th, 2017 @ 9 am CDT.
>
> Discuss amongst yourselves. :)
>
> Thanks,
> Sammy Kaye Powers
> sammyk.me
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Mike Willbanks]

On Fri, Jun 24, 2016 at 5:20 AM, Dmitry Stogov  wrote:

> Hi internals,
>
>
> Please review the RFC https://wiki.php.net/rfc/async_signals


I do not like the idea of introducing this via an INI directive, what might
be of value is to have a behavior on the function recommendation such that:

pcntl_async_signals([bool $enabled])

Without passing in the variable it could return back the current status
(enabled or not).  This provides userland a far more flexible handling.
The INI setting could cause some additional issues.  What is not clear is
can the INI setting be changed at runtime - so additional clarification is
needed there.  The main concern for this comes in when you build for
multiple consumers and do not control the environment.  This can cause
havok especially when you do need to have signals.


>
>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

[Mike Willbanks]

On Thu, May 12, 2016 at 12:33 PM, Sara Golemon  wrote:

> https://wiki.php.net/rfc/rfc.third-party-editing
>
> Let's make RFCs more useful before AND after voting!
>


Yes please!  It certainly would make it far easier to see the arguments for
and against and have a history of said arguments rather than searching the
mailing list and going through 100+ responses across 5 threads and weeding
through them.


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

Re: [PHP-DEV] Testing HTTP/2 support in PHP

[Mike Willbanks]

On Dec 30, 2015 5:29 PM, "Davey Shafik"  wrote:
>
> Hey all,
>
> In the PR for adding HTTP/2 Server Push support to curl, Julien raises the
> question of adding tests for this feature [1].
>
> This is currently very difficult.
>
> While we have the cli-server, it currently only supports HTTP/1.x. This
> means we need another httpd to test against that supports both HTTP/2 and
> server push — currently that means something like a node script using
> node-http2, or nghttpd (both of which have been what I tested the patch
> against).
>
> While I have a docker container for testing, this obviously doesn't fit
> well into `make tests`. The simplest solution along those lines is to
check
> for `node` and run a node daemon, but it doesn't scale well to lots of use
> cases, and is purely for testing.
>
> However, Rasmus raised the possibility of adding HTTP/2 support to the
> cli-server [2], and (someone? @php-pulls) suggested we pull in a third
> party lib to do the heavy lifting [3].
>
> My recommendation would be to use libnghttp2 [4] which curl also uses —
> however, as this adds a new dependency, I think it should be optional
(e.g.
> --with-nghttp2-dir=[PATH]), with it falling back to the current HTTP/1.x
> implementation.
>
> We could also add a flag (e.g. --[no-]http2) on the CLI for
> enabling/disabling it — this would be helpful for testing HTTP/2 client
> fallback when it's not supported.

I would prefer the second as http2 will be the standard to come. I'm not
even sure disabling it is worth it, but as you mention some may not want
the external library.

>
> This is a much more useful tool than relying on node for make tests, and
> allows us to test adding HTTP/2 support to ext/curl, the HTTP stream
(which
> could also use libnghttp2…), userland HTTP/2 clients, pecl_http (if that's
> still a thing), etc.

Agreed.

>
> Now, I don't think I have the ability to achieve this, but I'm willing to
> give it a go.
>
> At the very least, I'm more than happy to write up the RFC and work with
> someone on this.
>
> Thoughts?
>
> - Davey
>
> [1] https://github.com/php/php-src/pull/1692#issuecomment-166935246
> [2] https://github.com/php/php-src/pull/1692#issuecomment-166972540
> [3] https://github.com/php/php-src/pull/1692#issuecomment-166997465
> [4] https://nghttp2.org

Re: [PHP-DEV] Re: [RFC Discussion] Precise Session Management

[Mike Willbanks]

Hello Yasuo,

On Sun, Dec 20, 2015 at 7:01 PM, Yasuo Ohgaki  wrote:

> Hi all,
>
> On Sat, Dec 19, 2015 at 7:33 AM, Yasuo Ohgaki  wrote:
> > I would like to restart better session management for PHP 7.1.
> >
> > https://wiki.php.net/rfc/precise_session_management
> >
> > Although this RFC targets PHP 7.1, new session management
> > could be applied to older releases also if majority of us agree.
> > Please comment.
>
> I would like to write patch for this next week.
> If you have comment, please comment this week.
>

This week is hard due to several holidays, I would recommend postponing
discussion until after.


However, I will comment on a few things that I dislike of the RFC:

Exposing the internal state of the session via a key on the session
__SESSION_INTERNAL__ may be dangerous.  How are you preventing writes to
this area?  Is an exception or error thrown?  I also do not feel that it is
worth encoding this directly into the session value but would be of far
greater benefit to expose through functions and ensure it is not touched
and protected from user land.  Anything that messes with the $_SESSION can
cause major issues (for instance upload progress did this and can cause
session corruption in certain cases as it manipulates the session state).

I fully agree that session_regenerate_id needs some additional work.
Although. I do not think that the implementation here seems like the
correct path as a general comment.




>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Practical comparisons on PHP7

[Mike Willbanks]

Lester,

On Wed, Dec 9, 2015 at 1:02 PM, Lester Caine  wrote:

> On 09/12/15 16:24, Rowan Collins wrote:
> >> So as somebody already said, maybe your code or setup is really busted.
> >
> > Really busted, or spending all its time in a type of operation that ZE3
> > can't particularly optimize...
>
> But I'd like to understand why what is fairly simple PHP code is
> apparently not working as some of you seem to expect. Much of the
> original code goes back to PHP4 days and has been optimised and updated
> over the years and re-factored a couple of times. It's doing the jobs
> required and giving response times that clients are happy with in the
> sub second on intranets. The only PHP7 fixes so far is a few __construct
> changes from the original named constructor ... the rest of the code is
> already e_strict clean.
>

This states nothing of how the code was architected and therefore cannot
provide any realistic baseline as others have noted.  In addition to this,
your comparing apples to oranges.  The speed increases in PHP itself do not
always translate 100% to application performance.  Without looking at
execution performance on a function level and realizing what is actually
taking the time this is a worthless conversation to be frank.


>
> So where should I be looking to work out why PHP7 seems little better
> than PHP5. This code is ADOdb and Smarty based with templates which have
> developed over 10+ years and we can switch on page caching for the
> static material, but many sites are running with dynamic data such as
> calling clients from queues and displaying dynamic information pages.
>

ADOdb and Smarty have not had MAJOR releases in several years.  Smarty 3.1
was in 2011 while Smarty 3 was in 2010.  ADOdb's last major release was in
2007.These are your implementation details and things that YOU are
leveraging, these are not necessarily a standardized approach.  Page
caching changes things dramatically as now you're simply requiring things.
If your spending time in query execution then thats why there is no
significant gain.

Overall, profile your code, look at the cachegrind output in the case of
xdebug and then look at instruction time.  Then you will have an idea where
the time is being spent and can actually have a concrete discussion around
performance and what is actually taking the processing time.  Anything
short of that, including this reply is a waste of time for everyone on this
list.



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

[PHP-DEV] WIKI Account Request

[Mike Willbanks]

Hello Internals,

I had requested a wiki account (mwillbanks) as I would like to propose an
RFC on Object casts to scalar types.  This has previously been discussed
prior to scalar type hints and since we have those now coming into PHP 7, I
believe it would be a great time to take a look at this for 7.1 (Discussion
will not be immediate as focus needs to be put into 7.0)

The last RFC had gone inactive back from 2012:
https://wiki.php.net/rfc/object_cast_to_types and I have talked with
ircmaxell about doing something similar but making it more inline with STH
as well as supporting a generalized __cast.

The general cruft of it is to have objects have the ability to support:
+ __toInt
+ __toFloat
+ __toBool
+ __toArray
+ __cast

Removing the existing having __toScalar as it would no longer make sense in
this context.  __cast would be utilized more or less as function((int)
constant_type) where as it may mean PHP_TYPE_* as initial feedback on the
idea showed that it would be the most generalist approach and might be
useful in that context.

Regards,

Mike

Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator

[Mike Willbanks]

On Sun, Mar 15, 2015 at 10:07 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Netroby,

 On Mon, Mar 16, 2015 at 12:03 PM, Netroby hufeng1...@gmail.com wrote:

  Does the in support this kind of php code ?
 
  ```php
  ?php
  $arr = ['a', 'b', 'c'];
  for ($v in $arr) {
  echo $v;
  }
 
 
  ```
 
  I know javascript has this kind of support
 
 
 
 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in
 

 No. We have foreach for this.
 Shells support this syntax, too.
 It may be confusing for some users. Good point.



I had made this point earlier; not having it was not in particular a hurdle
for me but I did believe that if we added the in clause we could also
follow that type of for loop.

Re: [PHP-DEV] About declare(strict_types = 1)

[Mike Willbanks]

On Mon, Mar 16, 2015 at 2:12 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi all,

 On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz den...@birkholz.biz
 wrote:

  Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
lib.php
?php
  declare(strict_types = 1);
  function add(int $a, int $b) {
  }
  
?php
 add($_GET['a'], $_GET['b']);
  
that means, I need to add a lots of (int) while I try to call a
   function in a library which is not written by myself.
 
  that is not right and has been discussed a thousand times over.
  The declare changes the rules only for function calls in the file it is
  declared in.
 
  so:
  lib.php:
  ?php
  declare(strict_types = 1);
  function foo(int $a) {
  // no function call here
  }
  ?
  The declare here does just nothing.
 
  ?php
  require lib.php;
  foo(123); // will work
  ?
 
  ?php
  declare(strict_types = 1);
  require lib.php;
  foo(123); // will give an error
  ?
 

 If this kind of behavior is allowed, why strict mode is strict? It's not
 strict at all if mode could be overridden.

 strict_mode is just controlling errors, then it should be handled as
 error E_WARNING/E_TYPE or whatever.

 Even if what it controlling is error that can be overridden by caller, yet
 calling it strict is not correct. Proper name would be something
 like raise_type_error.

 Let see how it looks if strict_types is renamed to raise_type_error

 ?php
 declare(raise_type_error = 1);
 function foo(int $a) {
 // no function call here
 }
 ?
 The declare here does just nothing.

 ?php
 require lib.php;
 foo(123); // will work
 ?

 ?php
 declare(raise_type_error = 1);
 require lib.php;
 foo(123); // will give an error
 ?

 Is everyone feel OK with this??



That seems far more odd in my opinion.  I vastly prefer the first.

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

[Mike Willbanks]

Hi Mike,

On Mon, Mar 9, 2015 at 7:45 AM, Michael Wallner m...@php.net wrote:

 Hi, I’d like to start vote on RFC:continue_ob — any objections?

 https://wiki.php.net/rfc/continue_ob https://wiki.php.net/rfc/continue_ob
 


I think it would be good to put an example of why this is immensely useful
in the RFC.  Conditions such as when a user aborts but there is a
transactional situation where the output is necessary of publishing
elsewhere.

But yes, this is a huge +1.

Re: [PHP-DEV] Deprecate array()

[Mike Willbanks]

On Tue, Mar 3, 2015 at 11:10 AM, Adrian Parker 
i.am.hidden.somewh...@gmail.com wrote:

 Seeing it makes me vomit, IMHO.


Seeing $var = [] makes me vomit, IMHO.



 This is just a proposal, I know next to nothing about core PHP development.


On a serious note, this would never happen.  The short-array syntax was
just recently added.  It is also much like ?=$var;? vs. ?php echo $var;
? in several ways but echo wouldn't be deprecated.



 Regards, Adrian

Re: [PHP-DEV] A different user perspective on scalar type declarations

[Mike Willbanks]

Hello,

On Thu, Feb 26, 2015 at 12:49 PM, Dan Ackroyd dan...@basereality.com
wrote:

 On 26 February 2015 at 17:48, Zeev Suraski z...@zend.com wrote:
  From: Theodore Brown [mailto:theodor...@outlook.com]
  2. Strict types are important in some cases.
 
  I would *want* any value with the wrong type (even a string like
  26)
  to be flagged as an error when passed to a function expecting an
  integer.
 
 
  I agree completely;  However, such use cases like this are a lot less
  common than the situations where you do want sensible coercion to be
  allowed.


 That's just not true on medium to large code bases, and if you think
 that's true it's possibly an explanation of why you don't see why
 people want strict types so much.


I've worked on several very large and medium sized code bases and I would
prefer sensible coercion to be allowed here.  This is likely more a matter
of presence.  More information below.



 In most applications, the part of the code that is exposed to the
 outside world and has to convert strings or unknown types into known
 types is a very small layer at the outside edge of the application.


This is true, however, the types that you are receiving back form a
multitude of data sources might be in a mixed format (databases for example
often provide representation back as a string, non-json based web services
provide mainly as a string, etc).   While I know what my data looks like
and I know I am always going to get a string integer back I do not want
to have to type cast this each and every time.  Or that I have a boolean
integer representation that is in a string... You get the point.   Sure, I
could certainly go in and take 5 minutes and cast each one but I'm not
certain why the purpose is there... It specifically changes the
determination that PHP is a weakly typed language and all of a sudden I now
need to care that my string integer boolean is not actually a boolean.



 The vast majority of code written for non-trivial applications has no
 contact with the outside world. Instead it only communicates to other
 layers inside the application where the types required are fully
 known, and so the parameters passed should already be in the correct
 type. And so type coercion is at best unneeded, and usually not
 wanted.


Yes, we're talking about a service oriented architecture or busways, etc.
Even then, between multiple layers of the onion you might have things that
are going to [a]synchronous message queues, coming from extensions, going
against a file system, etc.  A non-trivial application has to go against
all of these things and the types might be different for each one of them.
For instance, PHP's integer does not handle a big integer from a database
after it exceeds a certain amount of digits, you have to speak binary to a
screen but you have an integer representation and then you might even need
to convert to a string octal in some points.  Overall, what I am saying
here is that it is a mixed bag of tricks and each developer happens to have
their preference to how the type system should and should not work.


 I can understand why people might only want to use weak types for
 their code base, but for you to continually dismiss people's desire
 for strict types after all this has been explained to you multiple
 times is very depressing.


I am not sure that Zeev is dismissing it so much as that he does not agree
with it and therefore he is doing his best to find an alternative that
remains within his vision of the PHP landscape.  That is why we have
multiple options on the table at this point.

Regards,

Mike

Re: [PHP-DEV] A different user perspective on scalar type declarations

[Mike Willbanks]

Anthony,

On Thu, Feb 26, 2015 at 1:29 PM, Anthony Ferrara ircmax...@gmail.com
wrote:

 Mike,

 One point of clarification:

  This is true, however, the types that you are receiving back form a
  multitude of data sources might be in a mixed format (databases for
 example
  often provide representation back as a string, non-json based web
 services
  provide mainly as a string, etc).   While I know what my data looks like
  and I know I am always going to get a string integer back I do not want
  to have to type cast this each and every time.  Or that I have a boolean
  integer representation that is in a string... You get the point.   Sure,
 I
  could certainly go in and take 5 minutes and cast each one but I'm not
  certain why the purpose is there... It specifically changes the
  determination that PHP is a weakly typed language and all of a sudden I
 now
  need to care that my string integer boolean is not actually a boolean.

 It's funny that you bring up boolean...

 With the current coercive proposal, you will still need to worry about
 the types: https://wiki.php.net/rfc/coercive_sth#coercion_rules


For some unbeknown reason I was inside of my head going ok, i have a string
integer so that would make an integer and then it would make a boolean.
Thank you for pointing out my obvious miss there :)




 Passing boolean(false) where an integer is expected will generate an
 error. This is a common practice, specifically around internal
 functions. Example:

 https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4eeea5fd9fe8916859a07430b94cf42/src/Util/ErrorHandler.php#L58

 So yes, you'll still need to go in and cast each one **in both RFCs**
 (or handle the errors properly).


This is certainly a common case, actually quite often for database purposes
do we need to handle booleans to integer conversions which my integer comes
back as a string (depending on which extension of course) and which type
field it is.



 The difference is with the dual-mode RFC you can choose not to have to
 cast and keep everything as-is today (or more specifically, you need
 to explicitly choose strict mode). And you can have user-land behave
 identically to internals **in both cases**.

 Anthony


Mike

Re: [PHP-DEV] A different user perspective on scalar type declarations

[Mike Willbanks]

Zeev,

On Thu, Feb 26, 2015 at 2:18 PM, Zeev Suraski z...@zend.com wrote:

  -Original Message-
  From: Mike Willbanks [mailto:pen...@gmail.com]
  Sent: Thursday, February 26, 2015 9:46 PM
  To: Anthony Ferrara
  Cc: Dan Ackroyd; Zeev Suraski; Theodore Brown; internals@lists.php.net
  Subject: Re: [PHP-DEV] A different user perspective on scalar type
  declarations
 
  Anthony,
 
 
  On Thu, Feb 26, 2015 at 1:29 PM, Anthony Ferrara ircmax...@gmail.com
  wrote:
 
 
Mike,
 
One point of clarification:
 
 This is true, however, the types that you are receiving back
 form a
 multitude of data sources might be in a mixed format (databases
  for example
 often provide representation back as a string, non-json based web
  services
 provide mainly as a string, etc).   While I know what my data
 looks
  like
 and I know I am always going to get a string integer back I do
 not
  want
 to have to type cast this each and every time.  Or that I have a
  boolean
 integer representation that is in a string... You get the point.
  Sure,
  I
 could certainly go in and take 5 minutes and cast each one but
 I'm
  not
 certain why the purpose is there... It specifically changes the
 determination that PHP is a weakly typed language and all of a
  sudden I now
 need to care that my string integer boolean is not actually a
  boolean.
 
It's funny that you bring up boolean...
 
With the current coercive proposal, you will still need to worry
 about
the types: https://wiki.php.net/rfc/coercive_sth#coercion_rules
 
 
  For some unbeknown reason I was inside of my head going ok, i have a
  string
  integer so that would make an integer and then it would make a boolean.
  Thank you for pointing out my obvious miss there :)
 
 
 
 
Passing boolean(false) where an integer is expected will generate
 an
error. This is a common practice, specifically around internal
functions. Example:
https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4ee
  ea5fd9fe8916859a07430b94cf42/src/Util/ErrorHandler.php#L58
 
So yes, you'll still need to go in and cast each one **in both
 RFCs**
(or handle the errors properly).
 
 
 
  This is certainly a common case, actually quite often for database
  purposes
  do we need to handle booleans to integer conversions which my integer
  comes back as a string (depending on which extension of course) and which
  type field it is.

 Can you explain that in a bit more detail?  What's the data flow exactly,
 in
 both directions?


Here is the most basic example and something that people are going to often
run into.  You see this type of code with hydrators, mappers, etc.
Ultimately the end result is going to be the same:

https://gist.github.com/mwillbanks/04e3be68f737c25984ab

I'm not certain if there is a need to explain that bit a bit more.  But a
string 1 as a bool should work as with a string 0.  For instance, today
we have the following for both string's 0 and 1:

$bool = 0;
var_dump($bool); // 0
var_dump($bool == false); // true
var_dump($bool == true); // false
var_dump($bool == 0); // true
var_dump($bool == 1); // false



 Thanks!

 Zeev

Re: [PHP-DEV] A different user perspective on scalar type declarations

[Mike Willbanks]

On Thu, Feb 26, 2015 at 3:15 PM, Zeev Suraski z...@zend.com wrote:

  -Original Message-
  From: Mike Willbanks [mailto:pen...@gmail.com]
  Sent: Thursday, February 26, 2015 10:43 PM
  To: Zeev Suraski
  Cc: PHP Internals
  Subject: Re: [PHP-DEV] A different user perspective on scalar type
  declarations
 
  Here is the most basic example and something that people are going to
  often
  run into.  You see this type of code with hydrators, mappers, etc.
  Ultimately
  the end result is going to be the same:
 
  https://gist.github.com/mwillbanks/04e3be68f737c25984ab
 
  I'm not certain if there is a need to explain that bit a bit more.  But a
  string
  1 as a bool should work as with a string 0.  For instance, today we
  have
  the following for both string's 0 and 1:
 
  $bool = 0;
 
  var_dump($bool); // 0
 
  var_dump($bool == false); // true
  var_dump($bool == true); // false
  var_dump($bool == 0); // true
  var_dump($bool == 1); // false

 OK, so essentially you're saying that you expect 1 and 0 to be coerced
 into booleans.  This is something we've been wondering about in the
 Coercive
 RFC, and in the original version we allowed all scalars to be coerced into
 bool - but not the other way around.  Right now the RFC only allows for
 integer-bool coercion, but the database use case seems to be a pretty
 strong one.  The options we considered were int only, int+string or none at
 all.  Float is the one that really stands out as pretty meaningless.


Yes, the database use case and exterior data has been my main concern over
the type hint proposals.  Now, this could also be changed (fixed, etc) on a
different layer (aka database extensions to deal with native types) but
that is likely far more to bite off than one would want at this point.  It
is relatively painless to go in and cast all of those types but the amount
of code out there which people are going to just 'expect' this to work will
be fairly large and one of those cases that will possibly be cause for
migration concerns.



 I think the opposite side is a lot trickier - converting from bool into
 string (or any other scalar type for that matter) is quite likely to hide
 bugs.  We've found a bunch of bugs like that today, where return values of
 strpos() are fed without validation into other APIs that expect an offset,
 and similar use cases.  Such code patterns are bound to be hiding bugs, at
 least in some cases.  I'm guessing that direction is less of an issue in
 your mind, correct?



Yes, direction is less of an issue.

Re: [PHP-DEV] [RFC] Anonymous Classes

[Mike Willbanks]

On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon pjsturg...@gmail.com
wrote:

 Good day!

 https://wiki.php.net/rfc/anonymous_classes

 There's a little RFC + patch that Joe Watkins put together, and as
 before with the ArrayOf RFC, I'll be helping out.

 So, lets get this discussion rolling.

 It was declined for PHP 5 some time ago, and has returned now to try for
 PHP 7.

 The usage of anonymous classes to some will be instantly offensive,
 but really it comes down to the use case. The usage of anonymous
 functions compared to declared functions is pretty much the exact same
 thing as anonymous classes.

 Other than examples on the RFC, Fractal would certainly be happy to
 have them: http://fractal.thephpleague.com/transformers/


I would also find myself to be a very happy consumer of this.  It can
provide the opportunity of getting rid of a large amount of boilerplate.
In addition, there has been several times when implementing single use
extensions for say view libraries (Plates extensions comes to mind) or
Plugin handling for things like Zend Framework 2 and there has been several
times I utilize a closure with an array to get around having an object
simply due to you want to have a callback but with some form of
definition.  I think there is a very large use case here and something that
would be a great addition to the language.  Sure, I could make a class and
extend it just like this would do but for the convenience of the
implementation it is sometimes better to do a simple closure.

Defining a class properly is certainly still going to be the majority
 of uses of classes in PHP. That helps with the Optimizer, and helps
 code reuse.

 Sadly due to the way in which people have had ONE CLASS ONE FILE
 drilled into their head since PEAR and continuing through Zend and
 PSR-0, it can become a PITA to add some simple functionality if a
 small class is needed for one tiny thing.


I see the point here, but the argument to me seems void.  Nothing wrong
with a simple class one file for a small class.



 Anonymous functions alleviate that annoyance with a simple and
 consistent feature that just give people a nice simple option to get
 their jobs done, without hitting autoloaders and file systems to do
 it.

Re: [PHP-DEV] User perspective on STH

[Mike Willbanks]

Hello,

I'm writing this as an author and maintainer of a framework and many
 libraries.
 Caveat, for those who aren't already aware: I work for Zend, and report to
 Zeev.
 If you feel that will make my points impartial, please feel free to stop
 reading, but I do think my points on STH bear some consideration.

 I've been following the STH proposals off and on. I voted for Andrea's
 proposal,
 and, behind the scenes, defended it to Zeev. On a lot of consideration,
 and as
 primarily a _consumer_ and _user_ of the language, I'm no longer convinced
 that
 a dual-mode proposal makes sense. I worry that it will lead to:

 - A split within the PHP community, consisting of those that do not use
   typehints, those who do use typehints, and those who use strict.
 - Poor programming practices and performance degradation by those who adopt
   strict, due to poor usage of type casting.

 Let me explain.

 The big problem currently is that the engine behavior around casting can
 lead to
 data loss quickly. As has been demonstrated elsewhere:

 $value = (int) '100 dogs'; // 100  - non-numeric trailing values are
 trimmed
 $value = (int) 'dog100';   // 0- non-numeric values leading
 values - 0 ...
 $value = (int) '-100'; // -100 - ... unless indicating sign.
 $value = (int) ' 100'; // 100  - space is trimmed; data loss!
 $value = (int) ' 100 ';// 100  - space is trimmed; data loss!
 $value = (int) '100.0';// 100  - probably correct, but loss of
 precision
 $value = (int) '100.7';// 100  - precision and data loss!
 $value = (int) 100.7;  // 100  - precision and data loss!
 $value = (int) 0x1A;   // 26   - hex
 $value = (int) '0x1A'; // 0- shouldn't this be 26? why is
 this different?
 $value = (int) true;   // 1- should this be cast?
 $value = (int) false;  // 0- should this be cast?
 $value = (int) null;   // 0- should this be cast?


I do think booleans should still be able to be cast from a user-land
perspective.  Often times a database does not deal with boolean values and
the quickest way to convert them into what the database needs is to cast to
an integer.
However, it's not like $value = ($value) ? 1 : 0 would be much worse.




 Today, without scalar type hints, we end up writing code that has to first
 validate that we have something we can use, and then cast it. This can
 often be
 done with ext/filter, but it's horribly verbose:

 $value = filter_var(
 $value,
 FILTER_VALIDATE_INT,
 FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX
 );
 if (false === $value) {
 // throw an exception?
 }

 Many people skip the validation step entirely for the more succinct:

 $value = (int) $value;

 And this is where problems occur, because this is when data loss occurs.

 What I've observed in my 15+ years of using PHP is that people _don't_
 validate;
 they either blindly accept data and assume it's of the correct type, or
 they
 blindly cast it without validation because writing that validation code is
 boring, verbose, and repetitive (I'm guilty of this myself!). Yes, you can
 offload that to libraries, but why introduce a new dependency in something
 as
 simple as a value object?

 The promise of STH is that the values will be properly coerced, so that if
 I
 write a function that expects an integer, but pass it something like '100'
 or
 '0x1A', it will be cast for me — but something that is not an integer and
 cannot
 be safely cast without data loss will be rejected, and an error can bubble
 up my
 stack or into my logs.

 Both the Dual-Mode and the new Coercive typehints RFCs provide this.

 The Dual-Mode, however, can potentially take us back to the same code we
 have
 today when strict mode is enabled.

 Now, you may argue that you won't need to cast the value in the first
 place,
 because STH! But what if the value you received is from a database? or
 from a
 web request you've made? Chances are, the data is in a string, but the
 _value_
 may be of another type. With weak/coercive mode, you just pass the data
 as-is,
 but with strict enabled, your choices are to either cast blindly, or to do
 the
 same validation/casting as before:

 $value = filter_var(
 $value,
 FILTER_VALIDATE_INT,
 FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX
 );
 if (false === $value) {
 // throw an exception?
 }

 Interestingly, this adds overhead to your application (more function
 calls), and
 makes it harder to read and to maintain. Ironically, I foresee strict as
 being
 a new badge of honor for many in the language (my code works under
 strict
 mode!), despite these factors.


This has been my largest concern of dual mode and something that I
completely see happening.



 If I don't enable strict mode on my code, and somebody else turns on
 strict when
 calling my code, there's the possibility of new errors if I do not 

Re: [PHP-DEV] [RFC] Big Integer Support

[Mike Willbanks]

On Tue, Feb 3, 2015 at 10:44 AM, Andrea Faulds a...@ajf.me wrote:


  On 3 Feb 2015, at 14:49, Lester Caine les...@lsces.co.uk wrote:
 
  On 03/02/15 14:03, Andrea Faulds wrote:
  But I don’t consider 0.25MB extra to be such a problem in practice. The
 PHP binary is already huge, and every system running PHP will have ample
 memory.
 
  Yes one approach is 'computers are getting faster with lots of memory'
  ... and for servers this is not a problem ...they will more than
  likely be 64bit anyway! But for smaller embedded devices php *IS*
  becoming an option so I don't have to program in C or something else,
  and then we look to strip everything that does not need to be present.

 Sure, but I don’t think we shouldn’t cripple the language merely for the
 sake of really low-end embedded devices. Also, I’m not convinced that the
 overhead, at least in terms of file size, is really that big of an issue.

 Just for you, I’ve gone and compiled the bigint branch (with LibTomMath)
 and master on my machine:

 $ ls -l php7-*
 -rwxr-xr-x  1 ajf  staff  6400408  3 Feb 16:39 php7-bigint
 -rwxr-xr-x  1 ajf  staff  6248920  3 Feb 16:42 php7-master

 The difference is a mere 151488 B, or 151 KB.

 Is that really so bad?


I would take 1MB if I had to so that I could have this in core.  I work
with them everyday and the pain of having to deal with them as strings is a
royal pain.  It would only become worse if this does not get into core and
type hints do as the mess would be drastic for any systems that must handle
64bit integers across the board.  It's not useful to have to always go to
gmp to handle numbers of this type.  It is simply not realistic.

On top of that, we use embedded systems everyday.  I have 6 devices sitting
in front of me right now.  Think of a GUID whereas they have large integer
internal representations and a hex representation for human readable.  On
top of this, we also have beaglebones and raspberry pi's that have internal
memory capacities where this easily fits and flash storage.  There is no
reason that this feature should be held back for embedded systems or even
system on a chip.

Regards,

Mike

Re: [PHP-DEV] in Operator

[Mike Willbanks]

Hello Pierre, Andrea and Niklas,

On Mon, Jan 19, 2015 at 11:35 PM, Pierre Joye pierre@gmail.com wrote:

 On Tue, Jan 20, 2015 at 6:15 AM, Andrea Faulds a...@ajf.me wrote:
  On 20 Jan 2015, at 03:30, Mike Willbanks pen...@gmail.com wrote:
 
  I am very familiar with the in operator.  However,  the implementation
  would be incomplete without handling loops via the in operator.  Many
  people when seeing an in operator also think of JavaScript.  In that
 case
  the in operator iterates over properties.  As such in PHP we should be
 able
  to iterate over associative arrays should the syntax be added.
 
 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in
 
  Why? We already have foreach/as which does exactly that, and unlike JS
 which added for/of, there’s nothing wrong with PHP’s foreach so we don’t
 need support for a new symbol.

 Indeed, exactly same feature.


It certainly is the same feature from the foreach perspective.  I'm not
against leaving it out, however, it would be much like the in operator thus
providing some additional syntax sugar.  Many people that often program in
JavaScript are used to having:
array.forEach(function()),  for (property in object), etc.

From my perspective it would seem like a hole in the implementation for it
to be missing but that is also due to having such a split of time between
the two languages.  Take for instance python utilizing the same thing:

for variable in expression:
... code
...

as well as ruby:

for variable [, variable ...] in expression [do]
   code
end

Ultimately, I would feel that having the in operator would also create the
expectation that in PHP we would be able to achieve the following:

for ($var in $array) {} and/or for ($var in $object) {};

Certainly foreach is more rich but I believe based on other languages and
paradigms that this would be something people would request and expect if
the in operator was to make it into PHP 7.

Regards,

Mike

Re: [PHP-DEV] in Operator

[Mike Willbanks]

Hello,

On Tue, Jan 20, 2015 at 7:47 AM, Marcio Almada marcio.w...@gmail.com
wrote:

 Hi,

 Mike, the use of in as `for ($var in $object) {};` could be the
 subject for another distinct RFC since it's doing something different
 from the original proposal:

 var_dump(PHP in [PHP, C, Java]); // true


It is indeed different but ever so slightly, a for loop in this case cannot
handle a single argument of true and would cause a parse error.

Therefore for (PHP in [PHP, C, Java]) could be handled differently.
Again, my main point is that due to other languages the in operator itself
also correlates to for ($var in $container), I understand having an
additional RFC but this is indeed the place for discussion of such things.

Also FYI - in the future please try not to top post and instead post under
where you are commenting as it makes it more difficult for people coming
later to the thread to see the scope of the conversation.

Regards,

Mike




 2015-01-20 10:41 GMT-03:00 Mike Willbanks pen...@gmail.com:
  Hello Pierre, Andrea and Niklas,
 
  On Mon, Jan 19, 2015 at 11:35 PM, Pierre Joye pierre@gmail.com
 wrote:
 
  On Tue, Jan 20, 2015 at 6:15 AM, Andrea Faulds a...@ajf.me wrote:
   On 20 Jan 2015, at 03:30, Mike Willbanks pen...@gmail.com wrote:
  
   I am very familiar with the in operator.  However,  the
 implementation
   would be incomplete without handling loops via the in operator.  Many
   people when seeing an in operator also think of JavaScript.  In that
  case
   the in operator iterates over properties.  As such in PHP we should
 be
  able
   to iterate over associative arrays should the syntax be added.
  
 
 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in
  
   Why? We already have foreach/as which does exactly that, and unlike JS
  which added for/of, there’s nothing wrong with PHP’s foreach so we don’t
  need support for a new symbol.
 
  Indeed, exactly same feature.
 
 
  It certainly is the same feature from the foreach perspective.  I'm not
  against leaving it out, however, it would be much like the in operator
 thus
  providing some additional syntax sugar.  Many people that often program
 in
  JavaScript are used to having:
  array.forEach(function()),  for (property in object), etc.
 
  From my perspective it would seem like a hole in the implementation for
 it
  to be missing but that is also due to having such a split of time between
  the two languages.  Take for instance python utilizing the same thing:
 
  for variable in expression:
  ... code
  ...
 
  as well as ruby:
 
  for variable [, variable ...] in expression [do]
 code
  end
 
  Ultimately, I would feel that having the in operator would also create
 the
  expectation that in PHP we would be able to achieve the following:
 
  for ($var in $array) {} and/or for ($var in $object) {};
 
  Certainly foreach is more rich but I believe based on other languages and
  paradigms that this would be something people would request and expect if
  the in operator was to make it into PHP 7.
 
  Regards,
 
  Mike

Re: [PHP-DEV] in Operator

[Mike Willbanks]

Hello Niklas,

On Sun, Jan 18, 2015 at 6:42 PM, Niklas Keller m...@kelunik.com wrote:

 Hello,

 I'd like to propose a new feature to PHP: The in Operator
 Bob mentioned a few weeks ago he wants such an operator in PHP and today I
 stumbled over

 http://nikic.github.io/2012/07/27/How-to-add-new-syntactic-features-to-PHP.html
 again,
 which uses the in operator as a sample.


I am very familiar with the in operator.  However,  the implementation
would be incomplete without handling loops via the in operator.  Many
people when seeing an in operator also think of JavaScript.  In that case
the in operator iterates over properties.  As such in PHP we should be able
to iterate over associative arrays should the syntax be added.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in


 Use cases:

 $obj = new StdClass;
 $obj-prop = value;
 $languages = [PHP, C, Java];
 var_dump(PHP in $languages); // true
 var_dump(Python in $languages); // false
 var_dump(0 in $languages); // false
 var_dump(0x0 in [0e3]); // false
 var_dump(prop in $obj); // true
 var_dump(foo in $obj); // false
 var_dump(Hello in Hello World!); // true

 For strings, it would replace `strpos(Hello World!, Hello) !== false)`,
 for arrays it would replace `in_array($needle, $haystack, true)`
 and for objects it would be a replacement of property_exists($class,
 $property)`.

 This change would mainly be syntax sugar, but I think it's worth because:
  * `0x0 in [0e3]` would return false while `in_array(0x0, [0e3])`
 returns true, that's probably an edge case, but there may be a lot of
 people that don't use the `$strict` parameter, see http://3v4l.org/0K7E5
  * It would solve the issue that it's hard to remember the order of the
 arguments for in_array and strpos, just had to look it up again.


I do think that it would be nice for a few different reasons but the in
operator as such can also cause a bit of confusion and misdirection
depending on how it is implemented.  In the use cases above you do mention
some inconsistencies with PHP functions that already exist.  Additionally
you did mention objects, in what scope would it properly leverage?  My
assumption would be visible properties from the context which you are in.

Regards,

Mike

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Mike Willbanks]

Hello Andrea,

On Thu, Jan 15, 2015 at 10:55 AM, Andrea Faulds a...@ajf.me wrote:

 Hey Levi,

 Upon further thought, I’m not super-enthusiastic about this. As has been
 pointed out, it’s a pretty serious BC break, whether code can be
 automatically updated or not. PHP 4 constructors may be obsolete, but an
 awful lot of code uses them.

 A better solution, IMO, might be simply to add a deprecation notice. This
 would make it obvious during development if you’ve accidentally defined a
 PHP4 constructor, and would encourage migration away from them, but
 wouldn’t prevent existing code from working.

 Thoughts?


I would be against a deprecation notice here.  In fact I think it should
either be do nothing or remove them entirely.  I know this thread has
become out of control but as a user of PHP 3, 4 and 5; a framework
developer; and a engineering executive I find that the PHP 4 style
constructors to be an ignorance that I am forced to currently deal with.

The amount of information in this post is vast and I don't feel I need to
go into details.  However, I support this proposal 100% as do I feel most
of the open source community.  Items that are still out there relying on
PEAR and other packages should remain on PHP 5 or even less.  We have
better solutions now such as composer which has changed the ecosystems
reliance on items such as PEAR.

Developers that are relying on PEAR have other issues to date than simply
what would happen with PHP 7 as not all PEAR packages work well with PHP 5
at this time especially the latest releases.  PEAR is a thing that has come
and gone.  Legacy code that still remains with PHP 4 style constructors
should upgrade to the latest.  Language evolve and we need to keep pushing
the bar forward.

As a personal note, PHP has slowly been moving towards the background for
certain applications for JavaScript (nodejs) and I feel for PHP to remain
it's competitive market it needs to evolve more as a leading language.  PHP
was great about this between 3, 4 and 5.  7 must do the same thing
otherwise I feel like it will lead to a slow death much like the perl of
old.

Regards,

Mike

Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator

[Mike Willbanks]

Hi Andrea,

On Mon, Jan 19, 2015 at 2:28 AM, Andrea Faulds a...@ajf.me wrote:

 Good morning,

 This is a reboot of Davey Shafik’s RFC (with permission). After recent
 discussions about sort functions, I was inspired to bring this back up, as
 I think it would be a useful feature.

 The RFC is here: https://wiki.php.net/rfc/combined-comparison-operator


I can only think of how many times I would have liked to have this over the
last decade.  Seems very straight forward and would be a perfect addition
for 7.

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Mike Willbanks]

Hello Andrea,

On Thu, Jan 15, 2015 at 8:09 AM, Andrea Faulds a...@ajf.me wrote:

 Hi Zeev,

  On 15 Jan 2015, at 11:56, Zeev Suraski z...@zend.com wrote:
 
  Andrea,
 
  I'm not sure what you're basing that assumption on.  The incidental
  interactions you (or anybody) may have with 'the community', by no way
  represent the opinion of the community at large.  The vast majority of
 the
  PHP community never ever interacts with internals@, never attend
  conferences, don't write blog posts about PHP and are generally
 completely
  'under the radar'.  I would actually go to argue that the people who do
  attend conferences, participate on internals@ or write blog posts - are
 not
  representative of the PHP userbase at large.  The vast majority of
  developers I bump into - you will never ever hear from.  They constitute
 the
  vast majority of the ~5M strong PHP developer base.
 
  So even though my belief / educated guess is that the vast majority of
 the
  PHP userbase would prefer to see strict typing kept off this language,
 I'm
  not going to argue that - but we must not argue the opposite either,
 based
  on the non-representative anecdotal data from a few dozen people.

 Whether or not they are in the majority, a very large portion of PHP
 developers would prefer strict typing. In particular, the most vocal ones
 would seem to. There are also a lot of PHP developers who would prefer weak
 typing. Thus we have a problem: either approach to scalar hints will upset
 a large portion of the community.


I actually quite disagree with that statement.  Both as a library/framework
developer and a user land developer I find strict typing to be more of an
issue.  For instance:

function foo(int $foo)
foo('23');

This would be a pain and cause constant glue from userland:
Option A: Force Cast aka (int) '23'
Option B: Check for digits via ctype_digits then force cast
etc.

To provide more of a point here, variables coming from HTTP are always a
string, this makes strict casting a troubling item, considering that the
main way of fetching input is coming from the web specifically.  I'm
certain this would also affect other areas as well such as reading csv
files and more.  To me this point alone makes a vastly strong statement
against strict typing and as such, it would make life far more difficult
for library developers and user land developers alike.



 
  Myself, I might have been somewhat happy with just weak hints, but
  it would upset an awful lot of developers who would like some measure of
  strict typing. Developers who would most likely not use the new scalar
  type
  hints, because they weren’t strict. And if nobody uses them, why add
 them?
 
  How do you deduce that 'nobody uses them' from the fact that some group
 of
  people said they won't?  I'm sorry, but it makes no sense, especially
 given
  the positive feedback you saw on internals, making it clear that there
 would
  be in fact people using it.

 Not all of it was positive. Sure, a lot of people would use them though,
 but I’ve heard quite a few developers say they wouldn’t use them and
 continue to use manual (!is_int($foo))-style assertions.

  If there's one thing that's worse than introducing an alien concept like
  strict typing into PHP, it's introducing it as a feature that will
 include
  all the negatives of this alien concept, PLUS have the ability to
 radically
  change how it behaves based on a runtime option.

 This isn’t a runtime option, it is entirely compile-time. Much like
 namespaces are not a runtime option. There isn’t even the ability to toggle
 it at runtime, unless we somehow add some ability to edit the flags on
 individual opcodes.


I agree with the others in that declarative syntax to change it is a bad
idea.  It actually reminds me of ECMAScript 5's use strict (
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode)
condition.   Changing the definition based on user land scripts can lead to
bugs and inconsistencies in a library developers purpose of a package and
cause bad conditions.  It also means that then a library developer would
need to handle conditions on both sides (when in weak vs. strict).  So I
don't really understand where the gains of this would come from and it
actually causes me concern in that what if a developer forgets to define
strict and you're entire system is built on strict.

Regards,

Mike

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Mike Willbanks]

Hi Andrea,



  On 15 Jan 2015, at 16:55, Mike Willbanks pen...@gmail.com wrote:
 
  I actually quite disagree with that statement.

 I don’t understand. I said either approach to scalar hints will upset a
 large portion of the community”. Are you not demonstrating that point, in
 that you don’t like the strict approach?


Sure, I am demonstrating that a bit, but I am of the opinion that either
will work but not both.  Whilst I prefer weak, I would take strict as well
to have something.  Having both would be a very strange inconsistency.
Sorry for not being more clear.  I would not be upset in either condition
but I certainly lead toward a certain direction.



   Both as a library/framework developer and a user land developer I find
 strict typing to be more of an issue.  For instance:
 
  function foo(int $foo)
  foo('23');
 
  This would be a pain and cause constant glue from userland:
  Option A: Force Cast aka (int) '23'
  Option B: Check for digits via ctype_digits then force cast
  etc.
 
  To provide more of a point here, variables coming from HTTP are always a
 string, this makes strict casting a troubling item, considering that the
 main way of fetching input is coming from the web specifically.  I'm
 certain this would also affect other areas as well such as reading csv
 files and more.  To me this point alone makes a vastly strong statement
 against strict typing and as such, it would make life far more difficult
 for library developers and user land developers alike.

 Well, this RFC doesn’t force you to use strict type checking. Quite the
 opposite.


  I agree with the others in that declarative syntax to change it is a bad
 idea.  It actually reminds me of ECMAScript 5's use strict (
 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode)
 condition.   Changing the definition based on user land scripts can lead to
 bugs and inconsistencies in a library developers purpose of a package and
 cause bad conditions.  It also means that then a library developer would
 need to handle conditions on both sides (when in weak vs. strict).

 No, the library developer would never need to “handle both cases”. Your
 library always gets the type it asks for. The RFC is quite clear on this.
 Your code will always behave exactly the same.


I may not have described this clearly.  If I make a library with a method
that states an int, the declarative syntax now makes me have to take both
due to your earlier comment on that userland would define the condition.
This means that if I declared handling inside my library to be strict but
the caller was in weak, I would need to handle that condition.  Now from
that perspective I cannot rely that I am in strict and would have to handle
the default weak even although I declared in my class that i wanted strict
mode which only affected the code inside of that file.  That's ultimately
what I am saying and why I am stating it would have to handle both
conditions.  In reality, you'd always act as if you were in a weak mode
supporting that case.

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

[Mike Willbanks]

On Sat, Jan 3, 2015 at 1:55 PM, Nikita Popov nikita@gmail.com wrote:

 Hi internals!

 I'd like to propose removing support for hexadecimal strings in the
 is_numeric_string() function, in order to achieve consistency with ordinary
 integer and float casts:

 https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings

 This change drops a WTF in our conversion semantics and should have low BC
 impact.


HUGE +1 here.  We commonly run into this WTF and becomes a cause for all
sorts of logic errors :)

Re: [PHP-DEV] ArrayPath

[Mike Willbanks]

On Tue, Oct 7, 2014 at 12:15 PM, Johannes Schlüter johan...@schlueters.de
wrote:

 On Tue, 2014-10-07 at 17:05 +0100, Mathias Grimm wrote:
  Hi,
  I would like to suggest something for php like a class I am using
 
  https://github.com/mathiasgrimm/arraypath
 
  The reason is to access arrays like this:
 
  $idx3 = ArrayPath::get('idx1/idx2/idx3', $_POST, 'myDefaultValue');

 what hppens if my array has a / as part of the key? Do I have to check
 that beforehand and set a custom identifier? So what happens if I use
 your example with $_GET instead of $_POST and a user requests
foo.php?idx1=idx2/idx3

 I'm not really convinced.



This request seems to be more in the realm of having XPath type support for
arrays, likewise people have also attempted to do this with JSON.  It does
seem like it could be valuable to some degree, however, I don't necessarily
believe it belongs in the core.  This seems much better for a PECL module
if necessary.

If the key has a / it would seem like you should escape it like a regular
string escape, aka \/.  I'm not convinced this is something that is
necessary in PHP either.  There does not seem to be a great use case for
this use.




 johannes


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

Re: [PHP-DEV] [PHP7] Remove the function keyword from class methods?

[Mike Willbanks]

On Fri, Oct 3, 2014 at 12:57 PM, Ingwie Phoenix ingwie2...@googlemail.com
wrote:


 Am 03.10.2014 um 19:38 schrieb Levi Morrison le...@php.net:

  On Fri, Oct 3, 2014 at 10:21 AM, Thomas Gossmann m...@gossimaniac.net
  wrote:
 
  Hey there,
 
  I'm just a php developer, thus not even having a php.net account.
 
  I was wondering if it is possible to deprecate/remove the function
 keyword
  from class methods in php7 or at least make it optional when one of the
  visibility keywords is present?
 
  I feel like writing a completely unnecessary keyword each time I write a
  new method for a class.
 
  I guess this was a discussion earlier, though I wasn't able to find
  anything about it. Would love to hear, what pdt-internals (re-)think
 about
  that topic.
 
  Thanks,
  gossi
 
 
  Removing the function keyword makes it more difficult for people to find
  method definitions. This has historically been a significant factor in
 why
  this hasn't been done.
 
  Also, what does this change actually bring to the table? There is no
 actual
  benefit to the language or tooling; in fact it probably makes the tooling
  more difficult. All this means is that the user types the function
 keyword
  less and saves a very, very small amount of time.
 
  In summary, historically we have felt that the benefits do not outweigh
 the
  drawbacks.


 I usually just observe on this list, but this is a topic I have come
 across myself.

 PHP has followed the C++ syntax, and logical scoping like namespace,s
 since a long time - if not, eversince. C++ does not use a function keyword
 by itself, and even lesser visibility keywords as PHP does.

 I find it rather ugly seeing „public function foo()“ everywhere, when
 everybody knows that parantheses mean function. So, I see readability as a
 plus.

 ?php class Foo {
 public bar($a, $b) { return $a+$b; }
 } ?

 It actually is not a drawback, but rather an enhancement that would
 increase PHP’s readability, in my opinion. It could be introduced as
 „syntactic shuggar“, where people can, but dont have to, use the function
 keyword. For the lexer, this just seems to be one more if().


I do not really agree with this point, whilst it is possible and creates
more concise structure, it changes a lot of things under the hoods...
Looking for a method and uncertain of the visibility in grep, vim, etc?
Have fun finding it... now you're doing expressions like
/(public|protected|private)\s+methodName/.  So while you saved typing in
function which your WPS as a programmer is quite high.  I doubt it is
going to make much of a difference for you.




 I don’t see a lot of evolution in PHP lately, so something small as this
 might be pretty nice! :)


I don't think you have been watching closely enough, there has been a ton
of evolutions lately...
https://wiki.php.net/rfc#php_70



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

Re: [PHP-DEV] make casts more strict in PHP 7

[Mike Willbanks]

 Hi!

  No, no it would not. PHP’s explicit casts cannot fail, and there is
  absolutely no good reason to change this. If people want strict
  casting, we can add new functions or operators for that specifically.
  But to break explicit casts and make them sometimes fail would cause
  innumerable bugs and backwards-compatibility ideas.

 I agree. If the developer explicitly states they want conversion, it
 should be conversion. For implicit casts, some tightening may be ok, but
 for explicit ones I think it would bring much more headaches than it's
 worth.


Precisely, it would cause a vast amount of headaches for many projects.
 Think of user input where you are expecting an integer and it must be a
positive integer (which would ultimately be a string); it is much faster to
do a quick check such as:

$foo = (int) $_GET['foo'];
if ($foo  0) {

}

I'd personally not have to wrap more items around it due to a notice or
warning.

Re: [PHP-DEV] RFC: Move phpng to master

[Mike Willbanks]

First off, I realize I am top posting but this thread is becoming extremely
off-topic, unbalanced and overall ridiculous to see from the sidelines as
someone that contributes to open source and also utilizes PHP on a daily
basis for more than the last decade.

Seriously, cut the shit!  Everyone is bringing this to a personal and
completely insane area; let's focus on the facts not the reactions wherever
they might come from.  Work together, no one ever agrees 100% of the time
and continuing on that note, no one makes the best choices 100% of the
time.  Surely, as a community we will not always agree on implementations,
timing and what is done in secret vs. not, what is more maintainable vs.
what is not.  Where to dedicate focus etc.  Open source projects often have
this issue.  Also, no I am not taking a stance or side on what is best for
the language.  People contributing to the engine are much smarter than I in
this level and the right choice I am certain will prevail.  But have a
reasonable conversations on facts vs. personal opinions and vendettas.

Now, PHP is a balanced language; performance comes with a cost if it be
memory, CPU spikes, maintainability, readability, etc.   We all program
here; this is always a trade off we need to determine, analyze and
identify.  These things have to be taken into account.  Documentation is
nice but not always necessary.  Depending on what it will change and how
much affect it will have on say extension developers and existing people
contributing to core has to be taken into account.

Let's get our heads straight, determine our focus for the next few years
and start to move forward.  Sure other languages gain and lose on PHP but
this will always be the case and should not be the core focus; we're not a
company that's on the stock market.  Languages will evolve, change, become
invented but it's not like PHP is going away in a rapid decline; sure there
is more languages and more competition out there.  For instance, I have
been writing node.js lately and find a massive benefit in certain types of
projects; it comes to utilizing the right tool for the right job.  Surely
you are not going to attempt to write PHP for something that should be done
in assembly or visa-versa.  Market share does affect our jobs and careers
but there is a reason the language has been successful and will continue to
be.  A speed increase is not a magical bullet here, if that was the case
and they wanted to use PHP they'd use HHVM or even Hack lang and change
their usage.  (Yes, there are other things there but come on, 99% of the
time core PHP speed is not the issue.)

Let's save the effort on this useless conversation, focus on driving
SOMETHING forward, WHATEVER that may be and stop taking everything so damn
personal.

Regards,

Mike


On Sun, Jul 27, 2014 at 7:18 PM, Kris Craig kris.cr...@gmail.com wrote:

 On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

  Hi all,
 
  On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner mike.php@gmail.com
 
  wrote:
 
 
  On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote:
  
  
  
  
   On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner 
  mike.php@gmail.com wrote:
  
  
   On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote:
   
Here's my question to counter yours, Michael:  What's the rush?
   
  
   Every day php-ng is not GA, PHP is losing ground to its competitors.
  
   Umm, how?  Do you have any data to support this?  According to
  http://php.net/usage.php, as of 2012, PHP's usage is steadily
  increasing.  As far as our competitors are concerned, well:
  
  
 
 http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
  
  
   As you can see, PHP continues to dominate with over 80% market share
  and no signs-- at least, none that I can see-- that we are losing
 ground
  as you stated.
  
 
  Surely it's wise to make the same wrong assumptions Microsoft did with
  Internet Explorer?
 
  PHP is losing as a general scripting language for sure.
  JavaScript is winning in this area even if it was originated as a web
  client scripting language.
 
  http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
  http://langpop.com/
 
  We are better to consider this situation seriously. IMHO.
  Focus on web as well as encourage general usage is what we need.
  Making PHP a choice for new project should be one of the most important
  objective.
 
  Regards,
 
  --
  Yasuo Ohgaki
  yohg...@ohgaki.net
 
 
 According to w3techs, JavaScript retains an extremely tiny market share in
 terms of general purpose languages:


 http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js


 It looks like the sources are all measuring different metrics.  It would be
 interesting to see a closer analysis of the data and figure out which
 metrics are the most relevant to this question.

 --Kris

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

[Mike Willbanks]

On Mon, Sep 23, 2013 at 7:29 PM, Yasuo Ohgaki wrote:

 Hi all,

 There isn't any good counter measure session hijack.
 However, we can regenerate session ID if IP address has changed.
 Hijacked users might notice that they have been logged out if session
 ID is regenerated by attackers. Therefore, users have slight chance
 to notice that they were under attack. It's not greatly effective, but
 better than nothing.

 Although this can be implemented in user script, it would be better if
 session module supports this behavior. Better security by default
 is good thing. It requires INI, since some apps may assume session
 ID would not change.
 (I do not encourage to use session ID for CSRF protection, but
 there are such implementations, for example.)

 A concern is that there are growing number of browsers share
 state. I do not research these browsers behavior yet. I suppose
 session cookie (expire=0) would not be shared.

 Anyone has any comments on this?


Each and every type of prevention measure has consequences and not only
that but MAJOR consequences.  If you are detecting IP changes you rule out
most if not all major proxy networks that exist.  While not first of mind;
when handling this you can easily remove the old session without properly
transitioning to the new.  This is an option based off of individual
application vs. a language option or construct.  There are a ton of
different measures that you might take based off of changes to the end user
data.  I think this would be a poor idea in the long run due to the
consequences that you may incur.

Re: [PHP-DEV] Gauging Interest:RFC to add map() function

[Mike Willbanks]

Hello Jeremy,


On Wed, Jun 26, 2013 at 8:20 AM, Jeremy Curcio j.cur...@icloud.com wrote:

 Hello,

 I would like to submit an RFC to add a new function to the PHP language.
 The function would be called map(). The purpose of this function would be
 to take an existing value within a range and make it to a corresponding
 location within a new range.


A map() function is normally part of functional programming and as such
would cause confusion and likely would not mean what most programmers would
assume.  See python and JS docs:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map
http://docs.python.org/2/howto/functional.html

Yes; we do have array_map; but I still do not assume that this would be
a mathematical function.



 The map() method would have 5 required parameters, $originalLow,
 $originalHigh, $newLow, $newHigh, and $value.

 map() would be implement the following:

 function map($originalLow, $originalHigh, $newLow, $newHigh, $value) {
 return $newLow + ($value - $originalLow) * ($newHigh - $newLow) /
 ($originalHigh- $originalLow);
 }


I am curious with something that is so easy; why would you want it in core?



 Example:
 Let's say we are teachers and are grading final exams. We have a policy
 that the best score is 100, and the worst score is a 70. Students scored
 between 55 and 92. We want to easily re-score the exams to be within the
 new score range, so we would use the new map() function. Let's begin with
 mapping the lowest score:

 $newScore = map(55, 92, 70, 100, 55); //$newScore = 70

 If we have all of our scores in an array:

 $scores = array(71, 65, 55, 85, 88, 86, 92, 77, 73);

 We could use a foreach loop to remap each value:

 $newScores = array();
 foreach($score as $scores) {
  $newScores[] = map(55, 92, 70, 100, $score);
 }
 var_dump($newScores);
 /*
 array(9) {
   [0]=
   float(82.972972972973)
   [1]=
   float(78.108108108108)
   [2]=
   int(70)
   [3]=
   float(94.324324324324)
   [4]=
   float(96.756756756757)
   [5]=
   float(95.135135135135)
   [6]=
   int(100)
   [7]=
   float(87.837837837838)
   [8]=
   float(84.594594594595)
   }
 */

 Just like that, we have the new exam grades that fit our policy, within
 the proper scale, without having to do any of the messy math ourselves.

 While I do recognize that this is somewhat trivial to anyone who knows the
 proper formula, I feel as though it would serve the PHP community well.
 Much the same as the pow() or pi() functions do. I appreciate your thoughts
 on this matter and whether or not this is worth pursuing as an RFC.

 Thank you,
 Jeremy Curcio
 j.cur...@me.com

Re: [PHP-DEV] [RFC] Simplified Array API for extensions

[Mike Willbanks]

On Tue, Apr 2, 2013 at 9:14 PM, Rasmus Lerdorf wrote:

 On 04/02/2013 07:52 PM, Sara Golemon wrote:
  https://wiki.php.net/rfc/php-array-api

 Very nice. I would love to see more of the API simplified for common
 tasks like this. It is a macro jungle currently.

 -Rasmus


Coming from a mostly user land developer but one that likes to attempt to
navigate the internals this is a massive step forward.  One of the hardest
things coming from the outside is attempting to navigate the macro jungle
as you call it.  lxr certainly helps a massive amount but even sometimes
understanding what those macros are supposed to be can a bit complex.

Navigating a cleaner API such as this I believe will assist in a cleaner
and much more clear implementation downstream.  These types of changes to
PHP can assist the PHP ecosystem in terms of contributors and overall
maintenance of the language.

- Mike

Re: [PHP-DEV] Add get_object_constants and get_class_constants

[Mike Willbanks]

  thank you! It is a useful feature to me.
 
  class MyBitmask {
const POS_1 = 1;
  //const POS_2 = 2;// reserved/undefined
  //const POS_3 = 3;// reserved/undefined
const POS_4 = 4;

 I'm developing software with PHP since version 2 and i'm still easily
 impressed by such code. So we need get_object_constants and
 get_class_constants for such fancy stuff?

 Where's the good old
 $flag == true; or FLAG == true;?

 A bitmask class to shuffle around with class constants using reflection
 of itself and a magic method get_class_constants to check a boolean flag?

 I just don't get it but maybe i'm to focused to doing things the most
 simple and readable/maintainable way.


The simple case of things like this is to be able to read extended classes;
say you are enforcing some type of bitmask checking; well extended classes
may not have the same signature.  Bitmasks are nothing new; PHP uses
several of them internally and several of them inside of various functions
(generally a bitmask would look more like:
0 = 0
1 = 1
00010 = 2
00100 = 4
01000 = 8
1 = 16



 Maybe, in a few years, c++ will be a beginners language compared to PHP
 which gets added new shiny features every day which will only be used by
 even more shiny frameworks and the most shiniest, bloated objects one
 can imagine.

 With every fancy feature added to PHP you kill a kitten!


This is not necessarily a new feature; it's simply rounding out some of the
already existing functions.  We're not talking about new framework
features; we are talking about ways to get things done quicker (although
the fractions of microseconds don't made a huge difference).  If you think
this is a new fancy feature; you likely think that this is the shiniest:
$class = new Reflection('MyClass');
$constants = $class-getConstants();

I'm more with this Give PHP and it's core developers a rest so that
 the core can be improved/cleaned up instead of adding Java features
 people have seen on the university and like them but now they're forced
 to use PHP which is like the opposite of Java. Java has it's good
 reasons too. Just a tool. Use the tool that fits best, don't use the
 hammer as a saw by adding teeth to it.


Funny enough; this is more PHP like than Java; the Reflection class is more
java oriented and already exists and is not touched in this.  We're talking
about global functions.  Sure give PHP a rest; but you know... I was
raising this simply for consistency; speed.  I am not asking anyone else to
work on this; hell part of the reason I submitted the PR before even
writing an RFC.

I am simply suggesting an alternative to using Reflection whereas:

get_class_constants([object|string]);
get_object_constants([object]);

Do we need both; probably not; the first would likely do.

Re: [PHP-DEV] Add get_object_constants and get_class_constants

[Mike Willbanks]

  I am simply suggesting an alternative to using Reflection whereas:

 get_class_constants([object|**string]);
 get_object_constants([object])**;

 Do we need both; probably not; the first would likely do.


 +1 for the first one only


 Am 27.02.2013 16:12, Analyst (Frank Schenk) trolled:

  bitmask class to shuffle around with class constants


 shuffle bits around with clearly named constants:
 http://php.net/manual/en/**language.operators.bitwise.phphttp://php.net/manual/en/language.operators.bitwise.php
 https://github.com/symfony/**symfony/blob/master/src/**
 Symfony/Component/Security/**Acl/Permission/MaskBuilder.phphttps://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Acl/Permission/MaskBuilder.php


This part of the example shows this in practice:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Acl/Permission/MaskBuilder.php#L192

You can see where it is using the reflection class to grab constants.
 These are the types of use cases where this becomes useful; now depending
on how many times this is done in a code base really depends on how useful
the function is over using the reflection class itself.

- Mike

[PHP-DEV] Add get_object_constants and get_class_constants

[Mike Willbanks]

Hello All,

Before drafting an RFC I would like to gauge interest in adding:
get_object_constants and get_class_constants

Currently this can only be done through ReflectionClass which is far slower
than retrieving them directly from the constants table.  Some simple
timings show that through reflection retrieving these values is 2-3 times
slower than providing a quick access function for retrieval.

This also fits nicely amongst the current stack of:
get_object_vars, get_class_vars and get_class_methods

These functions are commonly asked about on areas such as StackOverflow (
http://stackoverflow.com/questions/956401/can-i-get-consts-defined-on-a-php-class)
amongst other places on the net.

I have already drafted up a PR with the changes and supplemental data:
https://github.com/php/php-src/pull/292

Regards,

Mike

Re: [PHP-DEV] Add get_object_constants and get_class_constants

[Mike Willbanks]

  Before drafting an RFC I would like to gauge interest in adding:
  get_object_constants and get_class_constants
 
  I have already drafted up a PR with the changes and supplemental data:
  https://github.com/php/php-src/pull/292
 
 You took the time to make a PR, but not an RFC?  This should really be
 the other way around (if at all).


Yeah, part of it is that I want to learn the internals so if I have to
throw it away; I don't care too much about it.  Would be different if I
knew the internals far better than I do then I would likely start on that
path.  But I wanted to be able to see what the performance differences
were, how to achieve it as I don't want to be one of those... yeah PHP
should do this but I can't do the work... so I figure I'd start by writing
it and finding help along the way until I can figure it out. :)




  Currently this can only be done through ReflectionClass which is far
 slower
  than retrieving them directly from the constants table.  Some simple
  timings show that through reflection retrieving these values is 2-3
 times
  slower than providing a quick access function for retrieval.
 
  I don't quite see why we need this. The only argument seems to be
  performance and I'm not quite sure why performance would be relevant
 here.
  At least I can't imagine in what kind of code fetching the class
 constants
  is a bottleneck.
 
 I'm meh on the perf issue.  Yeah it's probably there, but it's buried
 in the noise and I'm not so sure about use-cases.  Not against it for
 its own sake though.


Many open source projects frown on the usage of Reflection and
ReflectionClass inside of the code base; this is part of the reason.  Sure
I could certainly use ReflectionClass and leverage that instead.  The
perception is that Reflection* is slow and as such by most maintainers it
is advised to stay away from it unless you're caching the results.  As
stated the performance is not necessarily a _huge_ case here; however, the
more places that this becomes incorporated in a code base the slower things
get overall.

Here is a simple use case of usage where MyClass2 can add in new constants
without having issue:
MyClass {
const SUCCESS = 1;
const FAILURE = -1;
const FAILURE_UNCATEGORIZED = -2;

public function __construct($code) {
$code = (int) $code;
if (!in_array($code, get_object_constants($this))) {
$code = self::FAILURE;
}
}
}
MyClass2 extends MyClass
{
const FAILURE_MYTYPE = -3;
}



  This also fits nicely amongst the current stack of:
  get_object_vars, get_class_vars and get_class_methods
 
 
 Yay! Consistency!  Boo! Poorly named get_*() methods should have been
 called something else from the get-go, but it's too late for that.
 Honestly, this is the bit that bugs me most.


Yeah; I just attempt to follow whatever is consistent in whichever area it
is.

I guess I am also curious here (not to divert from the thread) but if we do
not want to add in more of these; why don't we deprecate the usage of the
current get_class_vars, get_object_vars, get_class_methods, etc and attempt
to have everyone move over to the Reflection use case?
Obviously this would have to be in a major version but if as a language PHP
is moving things to the reflection use cases then provide it only there?
 Seriously not attempting to open up a can of worms here; there has already
been several threads on BC and deprecation in the last month or so overall
on the ML.



  These functions are commonly asked about on areas such as StackOverflow
 (
 
 
 http://stackoverflow.com/questions/956401/can-i-get-consts-defined-on-a-php-class
  )
  amongst other places on the net.
 
 
 I... kinda don't care about this part of the argument.  It's called
 Google, and if they can't find it in Reflection, they won't find it
 here.


That is semi true; I believe most people would locate
get_object_vars/get_class_vars and then are confused when they cannot get
the constants.   Still it is easy to locate the reflection so this argument
is easily dropped.

- Mike

[PHP-DEV] ArrayObject Fix: PR #289 Bug: #52861

[Mike Willbanks]

Hello All,

The reference issues I previously noted were mostly about unset not being a
proper write context when the ZE is tricked into thinking it is a
reference; this is used for both write and read write but not unset.

This causes countless issues where you are unable to unset a
multi-dimensional array when using ArrayObject.  You can do it IF and ONLY
IF each sub-array is an ArrayObject but in the context.  You can see how
the bug works here: https://github.com/php/php-src/pull/289

If at all possible it would be fantastic to have this fixed for PHP master,
5.5, 5.4 and even 5.3.  It causes a bunch of pain in userland especially if
you override $_SESSION with an ArrayObject or any other object for that
matter.

In ZF2 this has lead us to creating our own implementation of ArrayObject
simply to workaround this type of issue by using ArrayAccess and subsequent
friends.  This has its own drawbacks and issues.  For instance; assume that
you are setting a multi-dimensional array on ArrayObject:
$ar = new ArrayObject();
$ar['foo'] = array('bar' = 'foo');
unset($ar['foo']['bar']);

This would now fail and not remove the data as well as issue:
PHP Notice: Indirect modification of overloaded element of ArrayObject.

Since this is not a BC break and a bug fix that does have quite a bit of
impact it would be very nice to see if it can get fixed.  If not for PHP
5.3 (which most people are using as a LTS version), 5.4 would certainly be
a good start.

- Mike

[PHP-DEV] ArrayObject Odd Behavior

[Mike Willbanks]

Hello Again,

I wanted to bring back the topic I started on ArrayObject; I've been doing
a ton of work with ArrayObject lately and finding some odd behavior.
 Firstly it would be great to know if these are by design or bugs.
 Secondly there are some areas where it likely needs to be improved.

1: ArrayObject return by reference:
Yes, you can tell offsetGet and __get to return by a reference; however, in
the case of multi-dimensional arrays it will not work due to the internal
implementation of ArrayObject.  Internally it stores everything in a
private variable storage which is an instance of an ArrayObject.
 Unfortunately since it is a regular instance of an ArrayObject and not one
of the current declarations it will pose issues when attempting to unset
variables.

Example:
class myArrayObject extends ArrayObject
{
public function offsetGet($key) {
$var = $this-storage[$key];
return $var;
}
}
$ao = new myArrayObject(array('foo' = array('bar' = 'baz')));
unset($ao['foo']['bar']);
PHP Notice:  Indirect modification of overloaded element of myArrayObject
has no effect

2: ArrayObject and Iterators:
For some reason when you do an exchangeArray with an iterator, it basically
does a type cast leaving you with an array key of the iterator class name
appended with var.  Unfortunately this key is special or something
because it cannot be accessed, isset returns false but you can get to your
records by either foreach or shifting or popping the array.  Not really
certain if this is intended at all and if so might need to be reworked?

Example:
?php
class MyIterator implements Iterator
{
private $var = array();

public function __construct($array) {
if (is_array($array)) {
$this-var = $array;
}
}

public function rewind() {
reset($this-var);
}

public function current() {
return current($this-var);
}

public function key() {
return key($this-var);
}

public function next() {
return next($this-var);
}

public function valid() {
$key = key($this-var);
$var = ($key !== NULL  $key !== FALSE);
return $var;
}
}

$ao = new ArrayObject();
$mi = new MyIterator(array('foo' = 'bar'));
$ao-exchangeArray($mi);

$array = $ao-getArrayCopy();
var_dump($array);
var_dump(isset($array['MyIteratorvar']));
$params = array_shift($array);
var_dump($params);
var_dump(isset($params['foo']));

This will output:
array(1) {
  [MyIteratorvar]=
  array(1) {
[foo]=
string(3) bar
  }
}
bool(false)
array(1) {
  [foo]=
  string(3) bar
}
bool(true)


That one had me dumb founded for a while; you can see this behavior just as
easy by doing it directly on the iterator itself and type casting it to an
array.

Example:
$ir = new MyIterator(array('foo' = 'bar'));
var_dump((array) $ir);

Anyhow it would be good to know your thoughts; on these two things.  I
believe there is a bug ticket already for the first item; the second item
 I didn't see anything within the first few pages but maybe I'm searching
for it without the right keywords.

Thanks for listening!

Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics

[Mike Willbanks]

Hello,

 Already answered before. Performance is important. A native C
  implementation is much faster than a PHP code implementation.

 Well, that's always a safe assumption. But a shiny benchmark would be
 useful in this review.
 Interesting hard fact would to be know if -for the overall framework speed-
 it makes a significant difference with or without bytecode cache. Shaving
 off a few milliseconds, always cool. But percentages, more fascinating.


This is mostly relevant for performance in non-bytecode caches.  Just as
most autoloading that leverages include paths.  Same problem exists with the
main spl_autoload functionality if you do not define your own autoloader.


  Now, PHP has case-insensitive identifiers. This includes function names,
  class names, and not least namespaces.
 
  The proposed SplClassLoader would break that. Like PSR-0 it cannot
 satisfy
  class name requests case-insensitively. The implementation approach is
  indeterminate, depending on filesystem.
 
  Now the desire to enforce coding styles per autoloader will certainly
 come
  up as post-factum rationalization here. But I'd also like to assert()
 that this
  creeping-in is even less acceptable from a language design point of
 view.
 
  For PHP6 there were discussions to drop BC and make identifiers case-
  sensitive, just like in most other C-style languages. This has been shot
  down.
 
  PSR-0 focus on a solid approach of class definition.
  But at the same time it does not touch naming conventions, except for
  file system class locations.
  If you read the mandatory section of PSR-0 [2], you'll see it's pretty
  explicit there this:
 
  - Alphabetic characters in vendor names, namespaces, and class names
  may be of any combination of lower case and upper case.
 
  So anything you said about case-sensitiveness is not broken by PSR-0.


 Not sure if you understood, or just glanced over it, again.

 I see that your specification _mentions_ uppercase and lowercase
 characters.
 It falls flat on mentioning any of the implications of their presence
 however.

 You see, the only purpose an autoloader has is to map identifiers from
 the programming language onto filenames from the operating system.
 And there just happen to be functional differences between the two. Namely
 identifiers in PHP (like class names) are NOT case-sensitive. But filenames
 on the filesystem ARE. And then, on some other systems they ARE NOT.

 This is not even cursorily explained by your specification. The most basic
 autoloader requirement of defining an *explicit and dependable mapping*
 between the two identifier systems is not met. It only talks about class
 names
 and namespaces, but declares the translation onto filenames only by
 omission.

 Yes, it's obvious that it implies mixed-case filenames. But it seemingly
 ignores
 that this is a bidirectional dependency. Once you have mixed/fixed-case
 files,
 you CAN'T have case-insensitive class names anymore.


The current spl_autoload default behavior works on windows great but say you
use the default on linux with mixed case file names?  It's broken.  As it is
today in the spl_autoload (default, not custom) we already have a
bidirectional dependency.  Further what we are talking about here is that
there has been a major community adoption.  All we are really talking about
here is default behavior since you could easily extend such an object to
change the behavior of the loading much like spl_autoload.



 There's no need to start a discussion about this here, or file subsequent
 explanations. There was ample opportunity to do so on the FIG mailing list
 after dissident debate has been locked out. Now why the identifier handling
 discrepancy never occured to anyone in two years is beyond me. But it's
 also irrelevant.

 SplClassLoader anyway does not provide a language-compliant autoloader.
 It can fail system-dependent to load class files when the PSR-0 file naming
 is followed.
 The first instantiation of a class may behave differently from all
 subsequent:

 new \Test\UserThing;
 new \Test\Userthing;

 Might only work in this order, or the other, or maybe on Win-systems both
 cases.
 (Again, thanks for not debating coding standards, but PHP language
 behaviour here.)

 Much unlike spl_autoload() which defines the only rational mapping. (And
 you know, the custom autoloaders of some more contemporary frameworks,
 where this very technical side effect was at least discussed.)


This is an untruth.  If you read the default source for spl_autoload; if you
did not call spl_autoload_register with any values it does search through
the include path; it also converts everything to lowercase.  See the
following bug tickets:
https://bugs.php.net/bug.php?id=53065
https://bugs.php.net/bug.php?id=49852

There has been a previous thread on this subject as well (spl_autoload case
sensitivity):
http://marc.info/?l=php-internalsm=129336968406654w=3


 If you want to be critic, spl_autoload is a 

Re: [PHP-DEV] SplClassLoader

[Mike Willbanks]

I've been following this but not on the internal portions of PSR-0...

Why it is needed:
Currently all of the implementations on the autoloading side is pushed in
through a custom class or function inside of spl_autoload whereas the
registered autoloading takes place.  Currently each framework that utilizes
this implements it within their own source code:
* ZF:
http://framework.zend.com/apidoc/1.11/db_Loader_Autoloader.html#%5CZend_Loader_Autoloader
* Symfony: https://github.com/symfony/ClassLoader

By standardizing this inside of an extension gains us 2 very major features
(IMO):
1. Extension would force the standard but could be extended to add in
various needs in the event there is additional functionality.
2. Easier for someone to implement PSR-0 without having to create a custom
autoloader elsewhere

The speed of this should give us a slight bump (only slight seeing as w/o
the use of absolute paths apc doesn't really gain us anything).

Overall; it should clean up the various implementations that are scattered
about.  Additionally; this should gain greater acceptance and an easier
implementations by people creating their custom frameworks or leveraging
something such as PSR-0.

From the RFC prospective it does seem like many things are missing:
1. Examples
* The easiest example being that of a folder structure and class naming such
as in PSR-0 with the instance of the autoloader.
2. Use Cases
* Examples of framework cases... additionally extending framework libraries
in separate folders.

Regards,

Mike

On Mon, Oct 24, 2011 at 11:25 AM, Pierre Joye pierre@gmail.com wrote:

 hi,

 I'd to be in favor to include it. However I would like to hear more
 from the people behind PSR-0 to be sure that it is actually what is
 needed and to complete the RFC (it is rather missing real info,
 examples and tests).

 Please also update the patch and attach it to the RFC.

 Cheers,

 On Mon, Oct 24, 2011 at 4:47 PM, guilhermebla...@gmail.com
 guilhermebla...@gmail.com wrote:
  Hi internals,
 
  It's been a while since Stas accepted that, but it seems the class
  haven't been merged since then.
  What's the status of this? Can I expect SplClassLoader in 5.4.0?
 
  It seems it was approved, but wasn't merged and thread was lost in space.
 =(
 
  There's an RFC for it: https://wiki.php.net/rfc/splclassloader
  There's a patch for it: https://github.com/metagoto/splclassloader
 
  I'm not 100% sure the patch still works since it's been over 1 year
  since it was proposed... =\
 
  Cheers,
 
  On Fri, Jul 15, 2011 at 4:07 PM, Stas Malyshev smalys...@sugarcrm.com
 wrote:
  Hi!
 
  On 6/29/11 6:31 AM, Mike Willbanks wrote:
 
  There's a RFC covering this. There's a patch also.
 
  https://wiki.php.net/rfc/splclassloader
 
 
  This one seems to have fallen through the cracks?
 
  Well, nobody proposed it in time (especially not the RFC author :)
 
  * The other implementation I could see is to modify spl_autoload to be
  able
  to pass it a parameter for the auto loading type - right now it will
  attempt
  to autoload everything lowercase (been brought up a few times).
 
  I think the class looks better. I think RFC needs to be expanded with
  description of what the class actually does and how, and then if there
 are
  no objections I think we could take it into 5.4.0, since the
 implementation
  already exists.
  --
  Stanislav Malyshev, Software Architect
  SugarCRM: http://www.sugarcrm.com/
  (408)454-6900 ext. 227
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 
 
  --
  Guilherme Blanco
  Mobile: +55 (11) 8118-4422
  MSN: guilhermebla...@hotmail.com
  São Paulo - SP/Brazil
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 



 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Re: [PHP-DEV] SplClassLoader

[Mike Willbanks]

On Mon, Oct 24, 2011 at 10:20 AM, Peter Cowburn petercowb...@gmail.comwrote:

 On 24 October 2011 15:57, David Coallier dav...@php.net wrote:
  On 24 October 2011 16:53, Paul Dragoonis dragoo...@gmail.com wrote:
  On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com
  guilhermebla...@gmail.com wrote:
  Hi internals,
 
  It's been a while since Stas accepted that, but it seems the class
  haven't been merged since then.
  What's the status of this? Can I expect SplClassLoader in 5.4.0?
 
  It seems it was approved, but wasn't merged and thread was lost in
 space. =(
 
  There's an RFC for it: https://wiki.php.net/rfc/splclassloader
  There's a patch for it: https://github.com/metagoto/splclassloader
 
  If we can identify where we want it in the structure of the PHP
  project, I'll be happy to merge the implementation and modify the
  config files to have --enable-spl-autoloader or such.

 Forgive me for not reading the code (yet) but what need is there for
 an --enable-spl-autoloader flag?


I agree; I do not believe that there is a need for an enable flag in this
case.  It should just be there or not at all.



 What are peoples' thoughts on the name of the class? The word auto
 fits best with all that has come before, yet the proposal here uses
 class: what about SplAutoloader?  With the introduction of this new
 class, whatever the name, what happens to __autoload() and
 spl_autoload_register(), if anything? How many ways do we want/need to
 load a class?


I believe by calling a class SplAutoloader when there is already an
implementation of spl_autoload that does something very different it would
be advised to not name it of the same sort... this is what people would
start to think about.  The name SplClassLoader is much more specific.  If we
needed to keep the word Auto it would seem better named
SplClassAutoLoader.

spl_autoload is completely separate from __autoload today.  Also __autoload
does differ from the spl_autoload facility in several ways and is not
recommended even from the manual standpoint: www.php.net/autoload.
 Secondarily; a class loader cannot autoload functions - it is made to only
implement PSR-0 and nothing more.  While you may use spl_autoload to load
classes the implementation can also load in functions.  This class is really
just enforcing a specific standardization.

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

[Mike Willbanks]

forgot to include everyone on this response - sorry.

when building PHP using
  (I) ./configure --with-mysql --with-mysqli --with-pdo-mysql
 you currently get a build using the system default libmysql, usually
 in /us or
 such. Alternatively PHP can be built using
  (II) ./configure --with-mysqli=mysqlnd [...]
 to build the MySQL extensions using the mysqlnd library.

 I would like to change mysqlnd's config9.m4 file to build PHP using
 mysqlnd when being called in form (I). Users would still be able to
 enforce libmysql by passing a path, like /usr.

 There are two main reasons I see for this:
  a) Different libmysql versions have slightly different behavior,
 which shows in our tests. We can't have both, a good test coverage
 and cover all these differences. By using mysqlnd we have a clear
 behavior every PHP developer can rely on.
  b) We provide different extensions (pecl/mysqlnd_*) which
 improve/extend mysqlnd functionality. By having mysqlnd as default
 these are better usable by users.

 Opinions?

 Yes, do it!!!

 Also; while we're talking about it; can we do something about the default
 socket location OR change configuring it in 3 places for pdo_mysql; mysqli;
 mysql?!   Maybe a mysqlnd_default_socket - or autoconf magic (for instance
 RedHat/CentOS MySQL provided RPM's default to: /var/lib/mysql/mysql.sock;
 Ubuntu/Debian default is: /var/run/mysqld/mysqld.sock, lastly is the current
 php default and mysql source default of /tmp/mysql.sock).  It seems like it
 could do a quick check either by platform or check to see if it is already
 there to change the default on build.  Only reason for bringing this up is
 that I've been burned a few times on this one (for instance pdo_mysql is
 configured but mysqli was not for the default socket locations).

 Regards,

 Mike

Re: [PHP-DEV] SplClassLoader

[Mike Willbanks]

 There's a RFC covering this. There's a patch also.

 https://wiki.php.net/rfc/splclassloader


This one seems to have fallen through the cracks?

I know this would benefit many of the frameworks that are out there and give
a speed bump to people utilizing them.  Is this a possibility for 5.4?
* The other implementation I could see is to modify spl_autoload to be able
to pass it a parameter for the auto loading type - right now it will attempt
to autoload everything lowercase (been brought up a few times).


Regards,

Mike

[PHP-DEV] [Patch] GeoIP Tests

[Mike Willbanks]

I've gone through the GeoIP extension and ensured all of the tests now pass.

Bug Report: http://pecl.php.net/bugs/bug.php?id=22749
Patch File: http://blog.digitalstruct.com/patches/geoip-svn-tests.patch.txt

Also, it looks like the GeoIP extension is based on an extremely old
version, I am going to start looking to update this to get all of the new
constants that should exist into the extension.
A slight amount of behavior changed and should have been noted previously
for the test as CA is no longer a valid country code w/o a region in the
timeZone.c area of the GeoIP C API.

Someone with karma want to review and apply the patch for the tests?

Regards,

Mike

Re: [PHP-DEV] [RFC] Object oriented session handlers

[Mike Willbanks]

Forgot to keep the list on this one.

On Mon, Jun 6, 2011 at 11:19 AM, Mike Willbanks pen...@gmail.com wrote:

 A while ago I submitted a patch to allow session_set_save_handler() to
 accept a class, and support the inheritance of the default session
 handler's methods.

 The RFC has a more detailed description and the current patch:
 https://wiki.php.net/rfc/session-oo

 Changes since this was last discussed:
 - More sanity checking to prevent handlers being called in unexpected
 states
 - ZTS fixes

 Any thoughts?


 Unfortunately the class may cause a BC break due to the naming.  Although
 namespaces could help in reducing the potential scope of a BC break.

 This is a huge win for those of us with generally highly custom session
 handlers.  This has been a consistent point of pain and being able to
 extend rather than reimplement would be a very nice enhancement.

 Now on the new SessionHandler object; is this now utilized by default?  I
 seen the wrapper in the patch but it seems like  we utilize all of the
 existing code with modifications to also utilize an object?  Should
 the procedural way be deprecated at some point or is the plan to support
 both styles?

 Regards,

 Mike

Re: [PHP-DEV] annotations again

[Mike Willbanks]

Guilherme,

As per many of the conversations on annotations one of that hardest parts of
it is that there are generally 3 conversations going on about it when this
starts to be discussed.  It seems many threads are hi-jacked and I can
understand why.

I would like to state that annotations in the core may be a good idea;
however, we have PECL and PECL seems like the perfect place for this.  Quite
a few extensions have started off in PECL and made their way to the core and
several have been moved from the core to PECL.  To me annotations support
seems like it would be perfect in PECL.  Dedicated machines and virtual
machines for end users are higher than ever and they seem to continue to
grow.  This should easily allow folks to put in the PECL module as needed.

I would argue that the introduction of this into the core is adding more
feature bloat into the language that is not quite needed at this point.
 There are obviously several improvements that this would allow to be
improved and consistent: WSDL / JSON-RPC / XML-RPC / Doctrine / etc.

However, I feel extensions like Mongo / Memcached / Gearman have more to add
to the PHP core than adding annotations and they live in PECL.  Just
speaking from the practical point of view.  It is great that certain
projects that have utilized annotations and created a layer in user land to
make annotations a nice thing to utilize.  But to continue to argue this
point; it just does not seem logical other than the fact that a few projects
want to promote annotations should cause it to drop into the core.

I for one would like to see this go to PECL and see the up-take then
identify if it is needed for the next PHP release after 5.4.  It seems a bit
early and like it would be crammed into the PHP core without enough
discussion.  There are obviously many thoughts on this and it will take time
to sort out and implementation details then would be further down the trail
after some consensus is happening within this feature.

Regards,

Mike

Re: [PHP-DEV] Re: [PATCH] Bug #49852 Bug #53065 - Adding spl_autoload_case_sensitivity()

[Mike Willbanks]

I was just thinking about this again and have a working patch for this.

It seems like the only potential BC break is on linux if people were
using all lowercase paths.  To me it would seem like this is really
not the case or would happen only sometimes.  The quick solution is to
utilize the following patch:

Index: ext/spl/php_spl.c
===
--- ext/spl/php_spl.c   (revision 306413)
+++ ext/spl/php_spl.c   (working copy)
@@ -229,7 +229,7 @@
zval *result = NULL;
int ret;

-   class_file_len = spprintf(class_file, 0, %s%s, lc_name, 
file_extension);
+   class_file_len = spprintf(class_file, 0, %s%s, class_name, 
file_extension);

 #if DEFAULT_SLASH != '\\'
{


It would seem that this could be addressed for PHP Next with the BC
break (since it is very unlikely to really hit).

Regards,

Mike

On Tue, Feb 22, 2011 at 9:04 PM, Mike Willbanks pen...@gmail.com wrote:
 I think it would be better just to fix the issue in the code.  If you
 run include 'My/Path/To/File.php' does it lowercase it?  It does not.
 The expected behavior would to not lowercase it.  There are ways that
 this could be fixed directly in the code.  The only real requirement
 that it looks like the need for lowercase is for the hash table that
 is internally maintained by spl_autoload for the loading of classes.

 To fix this w/o a BC break and give the expected behavior, it could
 look for the class first by lowercasing the path and then secondarily
 look by the correct case (or the opposite).  The only real usefulness
 of the default behavior is for windows users whereas the majority of
 installs is on *nix platforms.

 The other way (and cleaner IMO) than the current patch if the above
 wouldn't work is to add a forth parameter to spl_autoload_register to
 tell it to by type sensitive.  The only BC break that is really
 possible here is for *nix users that are expecting it to always be
 lowercase, however, this seems to be more or less an edge case and
 should ultimately just be fixed.  I have not seen one project that
 utilizes the spl_autoload default functionality since their class
 naming structure generally consists of upper and lowercase letters.

 To keep consistency it could certainly be a boolean with the function
 declaration of (keeping BC of course):
 bool spl_autoload_register ([ callback $autoload_function [, bool
 $throw = true [, bool $prepend = false [, bool $case_sensitive = false
  )

 I can build a patch for this route if someone would like... I just
 think that instead of the SplClassLoader proposal something also needs
 to happen with the spl_autoload area as well.

 Regards,

 Mike

 Wouldn't it be better to join forces with the SplClassLoader proposal[1]?
 A C implementation of PSR-0 has been prpoposed [2] as well, and would be
 nice to get something like that into 5.next

 However for your imminent performance needs, you should be aware that an
 hash map based autoloaders can be fast as well [3].


 [1] http://wiki.php.net/rfc/splclassloader
 [2] http://blog.runpac.com/post/splclassloader-php-extension-benchmarks
 [3]
 http://weierophinney.net/matthew/archives/245-Autoloading-Benchmarks.html

 Best
 ar


 On Wed, Jan 12, 2011 at 11:53 PM, Marc Easen m...@easen.co.uk wrote:

 Hello again,

 Has anyone had a chance to look at my patch?

 Forgive me for being quite eager to get this into trunk, as it will improve
 the performance of all PHP Frameworks which currently implement their own
 autoloader method due to the oddities of the SPL autoloader.



 Kind Regards
 Marc


 On 26 Dec 2010, at 13:20, Marc Easen wrote:

 Hello everyone,

 Firstly I would like to introduce myself, my name is Marc Easen and I've
 working with PHP for past 6 years or so. I'm really excited to see where PHP
 is going with the addition of namespaces and now traits, and hopefully I'm
 able to contribute back to PHP community.

 I've currently working on a high performance PHP Framework based on version
 5.3.3+ (5.3.99-dev for traits). Due to the high performance nature of this
 framework I've been looking at ways of improving the loading of the classes.
 It seems by default the spl_autoload() function lowercases the class name
 before trying to locate the file, a couples of users have reported this
 previously and have requested a fix (bug #49852
 http://bugs.php.net/bug.php?id=49852  bug #53065
 http://bugs.php.net/bug.php?id=53065). spl_autoload() lower casing the
 class names when it is trying to locate the file does not work on *nix based
 system in a lot of PHP Frameworks - Zend Framework being on of them.

 Understanding the requirement to support backwards compatibility both
 submitters suggested implementing a spl_autoload_case_sensitivity()
 function. The patch I have attached adds such a function to the SPL
 extension. The patch is against trunk (r306670), it also includes phpt tests
 for this function.

 Please could someone review

Re: [PHP-DEV] Re: [PATCH] Bug #49852 Bug #53065 - Adding spl_autoload_case_sensitivity()

[Mike Willbanks]

Do you use lowercase paths and have capitals in your class names?
That is really where this goes into.  Much of PEAR and just about all
of the frameworks are following a specific area.  The main key item
here is that \My\Class is generally in a folder like My/Class.php.
Right now spl_autoload would translate this to look at: my/class.php
by default which one would likely think that it would be My/Class.php
being the one that would be autoloaded since we did not type it
lowercase.

Regards,

Mike

On Wed, Mar 9, 2011 at 1:06 PM, Michael Maclean
mich...@no-surprises.co.uk wrote:
 On 09/03/11 13:34, Mike Willbanks wrote:

 It seems like the only potential BC break is on linux if people were
 using all lowercase paths.  To me it would seem like this is really
 not the case or would happen only sometimes.

 I'd have trouble finding a single one of my apps that had a path with any
 uppercase characters at all. They all run on Linux.

 --
 Cheers,
 Michael


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

Re: [PHP-DEV] Re: [PATCH] Bug #49852 Bug #53065 - Adding spl_autoload_case_sensitivity()

[Mike Willbanks]

I think it would be better just to fix the issue in the code.  If you
run include 'My/Path/To/File.php' does it lowercase it?  It does not.
The expected behavior would to not lowercase it.  There are ways that
this could be fixed directly in the code.  The only real requirement
that it looks like the need for lowercase is for the hash table that
is internally maintained by spl_autoload for the loading of classes.

To fix this w/o a BC break and give the expected behavior, it could
look for the class first by lowercasing the path and then secondarily
look by the correct case (or the opposite).  The only real usefulness
of the default behavior is for windows users whereas the majority of
installs is on *nix platforms.

The other way (and cleaner IMO) than the current patch if the above
wouldn't work is to add a forth parameter to spl_autoload_register to
tell it to by type sensitive.  The only BC break that is really
possible here is for *nix users that are expecting it to always be
lowercase, however, this seems to be more or less an edge case and
should ultimately just be fixed.  I have not seen one project that
utilizes the spl_autoload default functionality since their class
naming structure generally consists of upper and lowercase letters.

To keep consistency it could certainly be a boolean with the function
declaration of (keeping BC of course):
bool spl_autoload_register ([ callback $autoload_function [, bool
$throw = true [, bool $prepend = false [, bool $case_sensitive = false
 )

I can build a patch for this route if someone would like... I just
think that instead of the SplClassLoader proposal something also needs
to happen with the spl_autoload area as well.

Regards,

Mike

 Wouldn't it be better to join forces with the SplClassLoader proposal[1]?
 A C implementation of PSR-0 has been prpoposed [2] as well, and would be
 nice to get something like that into 5.next

 However for your imminent performance needs, you should be aware that an
 hash map based autoloaders can be fast as well [3].


 [1] http://wiki.php.net/rfc/splclassloader
 [2] http://blog.runpac.com/post/splclassloader-php-extension-benchmarks
 [3]
 http://weierophinney.net/matthew/archives/245-Autoloading-Benchmarks.html

 Best
 ar


 On Wed, Jan 12, 2011 at 11:53 PM, Marc Easen m...@easen.co.uk wrote:

 Hello again,

 Has anyone had a chance to look at my patch?

 Forgive me for being quite eager to get this into trunk, as it will improve
 the performance of all PHP Frameworks which currently implement their own
 autoloader method due to the oddities of the SPL autoloader.



 Kind Regards
 Marc


 On 26 Dec 2010, at 13:20, Marc Easen wrote:

 Hello everyone,

 Firstly I would like to introduce myself, my name is Marc Easen and I've
 working with PHP for past 6 years or so. I'm really excited to see where PHP
 is going with the addition of namespaces and now traits, and hopefully I'm
 able to contribute back to PHP community.

 I've currently working on a high performance PHP Framework based on version
 5.3.3+ (5.3.99-dev for traits). Due to the high performance nature of this
 framework I've been looking at ways of improving the loading of the classes.
 It seems by default the spl_autoload() function lowercases the class name
 before trying to locate the file, a couples of users have reported this
 previously and have requested a fix (bug #49852
 http://bugs.php.net/bug.php?id=49852  bug #53065
 http://bugs.php.net/bug.php?id=53065). spl_autoload() lower casing the
 class names when it is trying to locate the file does not work on *nix based
 system in a lot of PHP Frameworks - Zend Framework being on of them.

 Understanding the requirement to support backwards compatibility both
 submitters suggested implementing a spl_autoload_case_sensitivity()
 function. The patch I have attached adds such a function to the SPL
 extension. The patch is against trunk (r306670), it also includes phpt tests
 for this function.

 Please could someone review this patch and let me know what you think.

 Kind Regards,

 Marc
 spl_autoload_case_sensitive.patch






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

Re: [PHP-DEV] Re: Sanity tally #2

[Mike Willbanks]

1. #3 - it is much cleaner to read than the other implementations in
resolving the conflict.  a different separator will be much harder to simply
see from a comparison.  in a state where many people are in fact doing code
reviews and as it gets larger into big business the easier to read is going
to be the best option (which is why #1 and #2 become difficult).  #4 could
have larger drawbacks in the terms of integration with existing projects or
could cause conflicts and frustration.
2. No opinion.

On Fri, Oct 17, 2008 at 12:08 PM, Steph Fox [EMAIL PROTECTED] wrote:

 Hi Stas,

  So far, my proposals hardly got any hearing at all, fair or otherwise -
 they were totally ignored on the vote - never even mentioned except for the
 note in Greg's wiki (which, despite being incorrect, was never fixed or
 changed), and it looks like at least some of the persons were under
 impression they vote for something I had proposed and in fact voted for
 something completely different.


 Don't worry, I'll work out some way to rectify that if needed (hopefully
 without flooding internals@ again). All we're really getting out of this
 straw poll is a broader picture of the elements that PHP users would or
 would not like to see.

 - Steph (4 votes to go)



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

Re: [PHP-DEV] PHP 4.4.9

[Mike Willbanks]

Hello,

On Mon, Jul 7, 2008 at 9:29 AM, Andi Gutmans [EMAIL PROTECTED] wrote:

  On Mon, 7 Jul 2008, Marcus Boerger wrote:
 
 Janusz is damn right here. Make the patches available but do not
   make it easy for people to stick to 4 please. Instead, stick to th
   eplan.
 
  We do, there are security fixes - we make a release.

 I'm with Derick here. We should push out new releases when there are
 security issues


While I mostly observe here, I would like to add some feedback from this
point of view.  With PHP 4, the date still has not been reached and if there
are security flaws they should be patched and released.  This should not be
sending mixed messages with the end of life announcement.  From the
enterprise perspective, we are out of compliance once the end of life has
been exceeded and internal policies will force many on PHP 4 to upgrade to
PHP 5 once that date has been reached.

Within these environments there might be legacy applications running on PHP
4 that are either waiting to reach their end of cycle or need to be upgraded
and the only way that does happen is when those timelines are reached when
the language reaches the end of it's life cycle.

Mike

Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision

[Mike Willbanks]

 I know they've been marked deprecated and all, but, really, what's
 the cost/penalty to having a couple functions around for legacy apps?


Then we will continue to be at the same old issue of they exist, people will
continue to use them and never move away from them.

Mike