date:20120803


Yahav Gindi Bar wrote:

Maybe I'm wrong when comparing with other languages and mainly with
ASP.NET(C#) since they've used it for web proposes but I did saw many
classes that used this feature and personally really like it.


If ASP is so good why is it loosing market share?
Personally I'm pulling all the ASP sites I've inherited to PHP simply because 
the basic work flow in them is so bad.
And on some of the inherited PHP sites we have this peculiar concept of having 
to write a 'controller' for a new page, and then another PHP file with the 
content. But then am I 'old fashioned' using smarty, templating and storing all 
the content in a database? This idea of 'controllers' and 'interfaces' does not 
seem to produce a viable work flow to me, and certainly unravelling the code is 
a pain :(



I've suggested to improve the language itself with some of the features in
runkit, not to copy and use it as is.


People don't use half of the facilities that PHP already has so why start 
introducing concepts that make that even more difficult. Once again ... we need 
to explain a lot better how to write 'good programs' using what is currently 
available without loading the core down with even more eye candy that few people 
will ever understand fully. I'm still for stripping more stuff back to PECL and 
coming up with a good 'old fashioned' simple beginners version of PHP to which 
the eye candy only needs adding once one understands the basics ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



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

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates


Adam Harvey wrote:

As an update, I've now pushed the remaining changes to /releases to
make this live (in the sense of being linked from somewhere). I've
left it in the sidebar for now, rather than adding it to the blurb on
that page.


Thanks for that useful crib sheet ...
Another useful reference to add would be the initial release date for each?
I could have sworn I was using PHP5 before 2004, but then it was in RC for a 
while and my first production machines were on an RC. But more interesting is 
that PHP4 was only around 4 years before that? One tends to forget what a short 
life some of these things HAVE had. So PHP4 was killed off 4 years after it had 
been superseded.


Hindsight is always a pain, but if PHP5.3 had been launched as PHP6, then we 
would have had another 4/5 year cycle, and would now be discussing PHP7 4 years 
later again ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



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

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates


Lester Caine wrote:

As an update, I've now pushed the remaining changes to /releases to
make this live (in the sense of being linked from somewhere). I've
left it in the sidebar for now, rather than adding it to the blurb on
that page.


Thanks for that useful crib sheet ...
Another useful reference to add would be the initial release date for each?
I could have sworn I was using PHP5 before 2004, but then it was in RC for a
while and my first production machines were on an RC. But more interesting is
that PHP4 was only around 4 years before that? One tends to forget what a short
life some of these things HAVE had. So PHP4 was killed off 4 years after it had
been superseded.

Hindsight is always a pain, but if PHP5.3 had been launched as PHP6, then we
would have had another 4/5 year cycle, and would now be discussing PHP7 4 years
later again ...


Just spotted a 'documentation problem' so should probably not be on this thread, 
but there is a gap in the links to windows binaries on the 'Unsupported 
Historical Releases' and in fact there does not seem to be a binary release 
available for PHP5.2.17? I can only find 5.2.16 in the windows archive ... AH 
there is a copy in the museum ... and windows support for PECL stopped in 2008.

I knew there was some reason 5.2.6 was still being used on windows systems ...

--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



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

Re: [PHP-DEV] Add runkit to PHP Runtime

Lester, you complain about practically everything being complicated/breaking 
compatibility/not working with PHP 5.2. Why complain here? It doesn't help the 
signal:noise ratio to moan about something which has no direct effect on you.


--
Sent from Samsung Mobile
Andrew Faulds
http://ajf.me/

Lester Caine les...@lsces.co.uk wrote:

Yahav Gindi Bar wrote:
 Maybe I'm wrong when comparing with other languages and mainly with
 ASP.NET(C#) since they've used it for web proposes but I did saw many
 classes that used this feature and personally really like it.

If ASP is so good why is it loosing market share?
Personally I'm pulling all the ASP sites I've inherited to PHP simply because 
the basic work flow in them is so bad.
And on some of the inherited PHP sites we have this peculiar concept of having 
to write a 'controller' for a new page, and then another PHP file with the 
content. But then am I 'old fashioned' using smarty, templating and storing all 
the content in a database? This idea of 'controllers' and 'interfaces' does not 
seem to produce a viable work flow to me, and certainly unravelling the code is 
a pain :(

 I've suggested to improve the language itself with some of the features in
 runkit, not to copy and use it as is.

People don't use half of the facilities that PHP already has so why start 
introducing concepts that make that even more difficult. Once again ... we need 
to explain a lot better how to write 'good programs' using what is currently 
available without loading the core down with even more eye candy that few 
people 
will ever understand fully. I'm still for stripping more stuff back to PECL and 
coming up with a good 'old fashioned' simple beginners version of PHP to which 
the eye candy only needs adding once one understands the basics ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



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

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

2012-08-03 Thread hakre

 Von: Adam Harvey ahar...@php.net

 Gesendet: 10:58 Donnerstag, 2.August 2012
 Betreff: Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates
 
 On 2 August 2012 16:51, Morgan L. Owens pack...@nznet.gen.nz wrote:
  On 2012-08-02 20:42, Peter Cowburn wrote:
  The details on things being obsoleted should be in the 
 migration guides.
 
  Then that would be where the links go, in a similar manner to the Changelog
  links.
 
 I've added links to the migration guides in the branch notes.
 
 Thoughts welcome once the mirrors update once again.
 
 Thanks,
 
 Adam

I'd say those are not EOL dates but the day of the last release per 
each branch. Especially if you compare that wording with:

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

and the definition of EOL that Rasmus gave - these dates are not 
the ones in the announcements, e.g. for PHP 4.4[1] for example:

End of Support Date: 2007-12-31
EOL Date: 2008-08-08
Last Release 2008-08-07

Another benefit would be to change the order in the table, example 
of both:

~~~

Unsupported Branches

This page lists the last release date for each unsupported branch of 
PHP. If you are using these releases, you are strongly urged to 
upgrade to a current version, as using older versions may expose you 
to security vulnerabilities and bugs that have been fixed in more 
recent versions of PHP.

Branch    Last Release    Date    Notes

~~~

Also it is probably worth to outline on that page that releases are 
not supported for historical reasons and that in the future the 
duration of support is as outline as in the RFC.

Also the page could have a prominent last updated timestamp as it 
contains information that obviously changes over time.

-- hakre

[1] http://www.php.net/archive/2007.php#2007-07-13-1

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

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

2012.08.03. 11:29, hakre hanskren...@yahoo.de ezt írta:

  Von: Adam Harvey ahar...@php.net

  Gesendet: 10:58 Donnerstag, 2.August 2012
  Betreff: Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates
 
  On 2 August 2012 16:51, Morgan L. Owens pack...@nznet.gen.nz wrote:
   On 2012-08-02 20:42, Peter Cowburn wrote:
   The details on things being obsoleted should be in the
  migration guides.
 
   Then that would be where the links go, in a similar manner to the
Changelog
   links.
 
  I've added links to the migration guides in the branch notes.
 
  Thoughts welcome once the mirrors update once again.
 
  Thanks,
 
  Adam

 I'd say those are not EOL dates but the day of the last release per
 each branch. Especially if you compare that wording with:

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

 and the definition of EOL that Rasmus gave - these dates are not
 the ones in the announcements, e.g. for PHP 4.4[1] for example:

 End of Support Date: 2007-12-31
 EOL Date: 2008-08-08
 Last Release 2008-08-07

 Another benefit would be to change the order in the table, example
 of both:

 ~~~

 Unsupported Branches

 This page lists the last release date for each unsupported branch of
 PHP. If you are using these releases, you are strongly urged to
 upgrade to a current version, as using older versions may expose you
 to security vulnerabilities and bugs that have been fixed in more
 recent versions of PHP.

 BranchLast ReleaseDateNotes

 ~~~

 Also it is probably worth to outline on that page that releases are
 not supported for historical reasons and that in the future the
 duration of support is as outline as in the RFC.

 Also the page could have a prominent last updated timestamp as it
 contains information that obviously changes over time.

 -- hakre

 [1] http://www.php.net/archive/2007.php#2007-07-13-1

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


The releaseprocess rfc is a recent one, it isn't applicable to the old
releases which predates the rfc.

Re: [PHP-DEV] Add runkit to PHP Runtime


Andrew Faulds wrote:

Lester, you complain about practically everything being complicated/breaking
compatibility/not working with PHP 5.2. Why complain here? It doesn't help the
signal:noise ratio to moan about something which has no direct effect on you.


When there is no negative responses it is taken that nobody objects to something 
being added. And currently even if we do object it still gets railroaded through 
on the basis we do not have to use it. Currently my main incomeis derived from 
using PHP so ALL of these changes have a direct effect on me ...


I've been put in touch with two major projects that are in the same boat as me 
currently and are now having to manage their transition from 5.2 to 5.4 on user 
sites so perhaps we can produce some usable documentation between us.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



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

Re: [PHP-DEV] Add runkit to PHP Runtime

2012-08-03 Thread Etienne Kneuss

On Fri, Aug 3, 2012 at 1:03 AM, Sara Golemon poll...@php.net wrote:
 For my vote: I think keeping this in pecl is fine, because they're all
 things which can be done from the extension space.

+1

 Yes, I've
 abandoned the package, but nothing is stopping someone else from
 taking it over.

It seems it has already been taken over: https://github.com/zenovich/runkit

-- 
Etienne Kneuss

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

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.

2012-08-03 Thread Hannes Magnusson

On Fri, Aug 3, 2012 at 8:08 AM, Leigh lei...@gmail.com wrote:
 Hi all,

 Can anyone explain to me the reason that when a function or class is
 disabled via the ini setting, an attempt to access the disabled item
 generates a non-fatal error?

Because there isn't anything actually wrong.

A fatal error is reserved for things we cannot recover from, but a
disabled function is easily recoverable.

-Hannes

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

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.

2012-08-03 Thread Leigh

 Because there isn't anything actually wrong.

 A fatal error is reserved for things we cannot recover from, but a
 disabled function is easily recoverable.

I don't see how it is any more recoverable than the function/class not
existing at all. How much code do you know of that checks for the
existence of every function it expects to be there, before using it?
The matter is even worse with classes, since creating a disabled class
does not return null. It returns an instantiated object with no
methods.

When an unexpected function is disabled, the engine can recover, sure.
The code, probably not. In my opinion it's better to stop the code
doing something potentially harmful than allowing it to continue with
bad data.

It seems inconsistent to me.

--

$a = new UndefinedClass; // PHP Fatal error:  Class 'UndefinedClass' not found

--

$a = new DisabledClass; // Warning
var_dump(get_class($a)); // string(13) disabledclass

--

$a = undefinedFunction(); // PHP Fatal error:  Call to undefined
function undefinedFunction()

--

$a = disabledFunction(); // Warning
var_dump($a); // null

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

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.

2012-08-03 Thread Etienne Kneuss

On Fri, Aug 3, 2012 at 1:59 PM, Leigh lei...@gmail.com wrote:
 Because there isn't anything actually wrong.

 A fatal error is reserved for things we cannot recover from, but a
 disabled function is easily recoverable.

Another great use-case for engine-thrown exceptions.

IMHO we should really rethink the let's not throw exceptions from the
engine/normal code so that people don't have to learn them


-- 
Etienne Kneuss

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

Re: [PHP-DEV] Add runkit to PHP Runtime

2012-08-03 Thread Yahav Gindi Bar

On Fri, Aug 3, 2012 at 10:23 AM, Lester Caine les...@lsces.co.uk wrote:

 Yahav Gindi Bar wrote:

 Maybe I'm wrong when comparing with other languages and mainly with
 ASP.NET(C#) since they've used it for web proposes but I did saw many

 classes that used this feature and personally really like it.


 If ASP is so good why is it loosing market share?
 Personally I'm pulling all the ASP sites I've inherited to PHP simply
 because the basic work flow in them is so bad.
 And on some of the inherited PHP sites we have this peculiar concept of
 having to write a 'controller' for a new page, and then another PHP file
 with the content. But then am I 'old fashioned' using smarty, templating
 and storing all the content in a database? This idea of 'controllers' and
 'interfaces' does not seem to produce a viable work flow to me, and
 certainly unravelling the code is a pain :(

 You may understood me in the wrong way - I'm not try to say that ASP.NETis so 
 good and make comparison in the negative way or something like that,
PHP is a different language with its own great pros and that's why I've
decided to join these discussions and try to help improving it to be even
better. I just saw a feature in C# which exists in other languages (I've
used Objective-C which got it, and I read that Python and Ruby also got it)
so I think it'll be great to have this ability too built-in in PHP, that's
all. As I've said earlier - without this ability built-in
many potential developers, and of course frameworks and software developers
can't relay on this feature.


  I've suggested to improve the language itself with some of the features in
 runkit, not to copy and use it as is.


 People don't use half of the facilities that PHP already has so why start
 introducing concepts that make that even more difficult. Once again ... we
 need to explain a lot better how to write 'good programs' using what is
 currently available without loading the core down with even more eye candy
 that few people will ever understand fully. I'm still for stripping more
 stuff back to PECL and coming up with a good 'old fashioned' simple
 beginners version of PHP to which the eye candy only needs adding once one
 understands the basics ...

 I don't think we can, even if we want, to teach beginners how to write
good programs or good-practice programs - there'll always be beginners
who'll create programs using bad-practice approaches and they'll improve by
the time, I guess... We can make the documentation better, but that's
a different thing (though take into account that many beginners even don't
know how to understand the documentation and point their questions to
support forums). For example, I know many beginners who don't know about
many built-in functions in PHP (even basic ones, array_map, strpos etc.), I
don't think that if we got an idea of function that can be useful for the
majority of the PHP community that we shouldn't include it because
beginners won't know about it or how to use it - being a beginner always
result in not know or understand features...

I think that the result of this way of thinking is restricting advance
programmers while beginners could stick with the basic features of PHP,
leaving the advance concepts until they'll be ready to learn them.

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.


Hi all,

Can anyone explain to me the reason that when a function or class is
disabled via the ini setting, an attempt to access the disabled item
generates a non-fatal error?

I'm looking at a segfault in the SPL caused by the blind creation of a
class, which seems to only fail when the class is disabled. I'm
wondering in how many other places this could occur.

The obvious solution is to be more careful and check return values,
but a FATAL would also have prevented execution continuing.

Thanks,

Leigh.


PHP has a long history of issuing errors of the wrong type at the wrong 
time. My experience shows it's best to have an error handler convert all 
errors to catchable exceptions, with some error types (like E_STRICT, 
E_ERROR etc.) to become instant fatal errors (can't be caught).


This would also solve your use case since the warning will become an 
exception with a stack trace clearly pointing to the origin of your problem. 
Additionally you can handle an exception on a higher level in the stack once 
instead of doing it for every function/class call.


I'm afraid fixing the default behavior is a big hopeless since it'll break 
BC and require a major rethinking of the way PHP issues errors.


See: set_error_handler().

Stan 



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

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.

2012-08-03 Thread Laruence

On Fri, Aug 3, 2012 at 3:08 PM, Leigh lei...@gmail.com wrote:
 Hi all,

 Can anyone explain to me the reason that when a function or class is
 disabled via the ini setting, an attempt to access the disabled item
 generates a non-fatal error?

 I'm looking at a segfault in the SPL caused by the blind creation of a
 class, which seems to only fail when the class is disabled. I'm
 wondering in how many other places this could occur.

 The obvious solution is to be more careful and check return values,
 but a FATAL would also have prevented execution continuing.

 Thanks,

 Leigh.
Hi:

this is a very badly bug.

but I think it's not a spl issues, we should change the behavior of
zend_disable_class,

since for now, it will delete the class entry, which will make the class entry
pointer (preserved by extension) become a wild pointer..

dereference it is a undefined behavior, in this sense, segfault is lucky.

thanks

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




-- 
Laruence  Xinchen Hui
http://www.laruence.com/

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

[PHP-DEV] missing documentation for use-clause in closures?

2012-08-03 Thread Rasmus Schultz

Is this all the documentation there is for the use-clause for
anonymous closures?

http://us2.php.net/manual/en/functions.anonymous.php

For one, it would be nice to have documentation that explains whether
the variables listed in the use-clause are copied/referenced at
declaration-time or at call-time?

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

Re: [PHP-DEV] missing documentation for use-clause in closures?

2012-08-03 Thread Peter Cowburn

On 3 August 2012 16:09, Rasmus Schultz ras...@mindplay.dk wrote:
 Is this all the documentation there is for the use-clause for
 anonymous closures?

 http://us2.php.net/manual/en/functions.anonymous.php

 For one, it would be nice to have documentation that explains whether
 the variables listed in the use-clause are copied/referenced at
 declaration-time or at call-time?


https://edit.php.net/  -- Go wild. :-)

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

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.

On Fri, Aug 3, 2012 at 4:19 PM, Stan Vass sv_for...@fmethod.com wrote:

 Hi all,

 Can anyone explain to me the reason that when a function or class is
 disabled via the ini setting, an attempt to access the disabled item
 generates a non-fatal error?

 I'm looking at a segfault in the SPL caused by the blind creation of a
 class, which seems to only fail when the class is disabled. I'm
 wondering in how many other places this could occur.

 The obvious solution is to be more careful and check return values,
 but a FATAL would also have prevented execution continuing.

 Thanks,

 Leigh.


 PHP has a long history of issuing errors of the wrong type at the wrong
 time. My experience shows it's best to have an error handler convert all
 errors to catchable exceptions, with some error types (like E_STRICT,
 E_ERROR etc.) to become instant fatal errors (can't be caught).

 This would also solve your use case since the warning will become an
 exception with a stack trace clearly pointing to the origin of your
 problem. Additionally you can handle an exception on a higher level in the
 stack once instead of doing it for every function/class call.

 I'm afraid fixing the default behavior is a big hopeless since it'll break
 BC and require a major rethinking of the way PHP issues errors.

 See: set_error_handler().


a php function/operation can raise more than one warning, how would you
handle that?
with exceptions you would only get the first one.
another issue is that with the current error handling model a call can
trigger a non-fatal error and still return some data.
with exeptions you can't do that.
so changing our internal error handling isn't as easy to start throwing
ErrorException-s, it would require much more workthan that.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.


On 03/08/12 16:50, Ferenc Kovacs wrote:

On Fri, Aug 3, 2012 at 4:19 PM, Stan Vass sv_for...@fmethod.com wrote:


Hi all,

Can anyone explain to me the reason that when a function or class is
disabled via the ini setting, an attempt to access the disabled item
generates a non-fatal error?

I'm looking at a segfault in the SPL caused by the blind creation of a
class, which seems to only fail when the class is disabled. I'm
wondering in how many other places this could occur.

The obvious solution is to be more careful and check return values,
but a FATAL would also have prevented execution continuing.

Thanks,

Leigh.


PHP has a long history of issuing errors of the wrong type at the wrong
time. My experience shows it's best to have an error handler convert all
errors to catchable exceptions, with some error types (like E_STRICT,
E_ERROR etc.) to become instant fatal errors (can't be caught).

This would also solve your use case since the warning will become an
exception with a stack trace clearly pointing to the origin of your
problem. Additionally you can handle an exception on a higher level in the
stack once instead of doing it for every function/class call.

I'm afraid fixing the default behavior is a big hopeless since it'll break
BC and require a major rethinking of the way PHP issues errors.

See: set_error_handler().



a php function/operation can raise more than one warning, how would you
handle that?
with exceptions you would only get the first one.
another issue is that with the current error handling model a call can
trigger a non-fatal error and still return some data.
with exeptions you can't do that.
so changing our internal error handling isn't as easy to start throwing
ErrorException-s, it would require much more workthan that.

Warnings are special, they aren't really errors as such. They wouldn't 
become exceptions.


Also, why should an erroring function return a value?

--
Andrew Faulds
http://ajf.me/


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

Re: [PHP-DEV] missing documentation for use-clause in closures?

On Fri, Aug 3, 2012 at 5:09 PM, Rasmus Schultz ras...@mindplay.dk wrote:

 Is this all the documentation there is for the use-clause for
 anonymous closures?

 http://us2.php.net/manual/en/functions.anonymous.php

 For one, it would be nice to have documentation that explains whether
 the variables listed in the use-clause are copied/referenced at
 declaration-time or at call-time?

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


would be nice having more docs on that.
there are the two rfc's:  https://wiki.php.net/rfc/closures  and
https://wiki.php.net/rfc/closures/object-extension  but make sure to test
because AFAIR the rfc is a little bit behind the current implementation.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.



  Warnings are special, they aren't really errors as such. They wouldn't
 become exceptions.

 Also, why should an erroring function return a value?


from
My experience shows it's best to have an error handler convert all errors
to catchable exceptions, with some error types (like E_STRICT, E_ERROR
etc.) to become instant fatal errors (can't be caught).
I think he is talking about turning everything(E_NOTICE, E_WARNING, etc.)
into exceptions except a few, which can't be catched (why should E_STRICT
be uncatchable?! ).
Which brings up the issues that I mentioned before.
Getting the return of an erroring function isn't such a big issue, but
turning everything into exceptions would prevent getting any return value
from any function/operation which triggers anything,

Personally I think that turning everything into exceptions is a bad idea,
and it would make stuff which possible currently impossible.
On the other hand, I think that we have many E_ERROR which could be turned
into E_RECOVERABLE_ERROR.
Which in turn could be turned into Exception by an userland error handler
if the php userland developer wishes it.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] missing documentation for use-clause in closures?

On Fri, Aug 3, 2012 at 5:53 PM, Ferenc Kovacs tyr...@gmail.com wrote:



 On Fri, Aug 3, 2012 at 5:09 PM, Rasmus Schultz ras...@mindplay.dk wrote:

 Is this all the documentation there is for the use-clause for
 anonymous closures?

 http://us2.php.net/manual/en/functions.anonymous.php

 For one, it would be nice to have documentation that explains whether
 the variables listed in the use-clause are copied/referenced at
 declaration-time or at call-time?

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


 would be nice having more docs on that.
 there are the two rfc's:  https://wiki.php.net/rfc/closures  and
 https://wiki.php.net/rfc/closures/object-extension  but make sure to test
 because AFAIR the rfc is a little bit behind the current implementation.



See also the discussion at
http://www.mail-archive.com/internals@lists.php.net/msg53817.html

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.


On 03/08/12 17:04, Ferenc Kovacs wrote:



Warnings are special, they aren't really errors as such. They
wouldn't become exceptions.

Also, why should an erroring function return a value?


from
My experience shows it's best to have an error handler convert all 
errors to catchable exceptions, with some error types (like E_STRICT, 
E_ERROR etc.) to become instant fatal errors (can't be caught).
I think he is talking about turning everything(E_NOTICE, E_WARNING, 
etc.) into exceptions except a few, which can't be catched (why should 
E_STRICT be uncatchable?! ).
Of course some can't be caught. The kind that can't are ones that can't 
be for obvious reasons. Runtime errors, for instance.

Which brings up the issues that I mentioned before.
Getting the return of an erroring function isn't such a big issue, but 
turning everything into exceptions would prevent getting any return 
value from any function/operation which triggers anything,
I don't see how the return value is needed if it has errored. Warnings 
are different, but they wouldn't become exceptions.


Personally I think that turning everything into exceptions is a bad 
idea, and it would make stuff which possible currently impossible.
Examples, please? I think making more things into exceptions, and hence 
catchable, makes more stuff possible (recovering from trying to use 
non-existent functions, for example)
On the other hand, I think that we have many E_ERROR which could be 
turned into E_RECOVERABLE_ERROR.
Which in turn could be turned into Exception by an userland error 
handler if the php userland developer wishes it.

Why not just have them exceptions in the first place?


--
Ferenc Kovács
@Tyr43l - http://tyrael.hu



--
Andrew Faulds
http://ajf.me/

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.


  a php function/operation can raise more than one warning, how would you 
handle that?
  with exceptions you would only get the first one.
  another issue is that with the current error handling model a call can 
trigger a non-fatal error and still return some data.
  with exeptions you can't do that.
  so changing our internal error handling isn't as easy to start throwing 
ErrorException-s, it would require much more workthan that.


Yes it is a bit more work than that. For example include issues two errors on 
include failure, I mute one of them and turn the other into an exception, which 
is one of the behaviors you've mentioned. There are ways to fix everything, but 
you have to be specific, if you want me to be specific as well.

Either way I'm trying to give a practical solution you can implement today. 
Aside from practicality, I do also support the idea that accessing disabled 
symbols should be a fatal error, not a warning.

Stan

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.

  Which brings up the issues that I mentioned before.

  Getting the return of an erroring function isn't such a big issue, but 
turning everything into exceptions would prevent getting any return value from 
any function/operation which triggers anything,

Maybe you want to keep your cake and eat it too, but in practice, functions 
which return useful content and also error are simply poorly designed.
You can work around such function, for example if I absolutely need both 
channels, exception AND return value, I have this:

1) switch the error handler in a temporary mode which logs errors in an array 
without throwing them.
2) call the offending function
3) preserve the return value and read the log
4) create an exception class instance which contains all needed data
5) throw it.

Alternatively I can choose to just return the value and not throw anything, 
depends what makes most sense. I wrap this once and then I can call it just as 
usual, getting both channels. BUT, this is very rare, and is a sign of a poor 
design of the function IMHO.

Stan

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.

2012-08-03 Thread Stas Malyshev

Hi!

 I'm looking at a segfault in the SPL caused by the blind creation of a
 class, which seems to only fail when the class is disabled. I'm
 wondering in how many other places this could occur.

This seems to be pretty bad. I'd say creation of an instance of disabled
class should be a fatal error, but regardless SPL should handle returns
properly. Did you submit a bug about the SPL problem?

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

Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.

2012-08-03 Thread Laruence

On Sat, Aug 4, 2012 at 12:47 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 I'm looking at a segfault in the SPL caused by the blind creation of a
 class, which seems to only fail when the class is disabled. I'm
 wondering in how many other places this could occur.

 This seems to be pretty bad. I'd say creation of an instance of disabled
 class should be a fatal error, but regardless SPL should handle returns
 properly. Did you submit a bug about the SPL problem?

I think it's https://bugs.php.net/bug.php?id=62737

thanks

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




-- 
Laruence  Xinchen Hui
http://www.laruence.com/

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

[PHP-DEV] Error handling brainstorming

Hi,

We started a discussion about the current error handling mechanism and the
possible improvements in the Why do disabled functions / classes generate
a WARNING thread[1], but that is a little bit offtopic there, so I decided
to create a separate thread for it.
Basically Etienne mentioned that the original issue was a good example why
would we reconsider throwing exceptions from the core, which is currently
discouraged.[2]
Stan replied with the idea of turning the current error handling mechanism
in php into using Exceptions for everything, but keeping some error types
as is/uncatchable. [3]
This was brought up on the lists multiple times, we even have two separate
RFC with similar idea.[4][5]
I tried to explain why I think is impossible to achieve the same
functionality by turning the php errors into exceptions without a major
overhaul in the engine[6][7], but it seems that I failed to do so.

First of all, I would like to clear up the few misunderstandings:

Stan:
You mentioned that E_STRICT (and E_ERROR but I see no problem with that)
should be instant fatal error, I think that was only a typo on your part,
could you please clear that up?
I would also ask you to confirm that you would like to see every error
levels[8] turned into exceptions except the non-recoverable ones. It seems
that you and Andrew disagree on that.

Andrew:
From your mails, it seems that you don't agree with Stan on turning
everything but fatals into exceptions[9].
I'm really confused about that, as if we take away warnings (and by that
logic everything else which is less serious than a warning) the we would
only have the fatal errors (which we already discussed to not turn into
exceptions and you also seemed to agree[10]), E_USER
and E_RECOVERABLE_ERROR.
Is this what you propose?

My opinion (and this is what I tried to explain to you) is that it is
pretty common in the core and the bundled extensions to raise notices and
warnings left and right, and still do something,
If we would turn anything less serious than E_RECOVERABLE_ERROR (so any
notice, deprecation notice, strict notice or warning)into an exception,
that would be a huuge BC break.
Basically silecing errors through setting error_reporting level, custom
error handlers or the @ operator would stop working, and one should put
everything into a try-catch block to not have his code blown into his code
constantly.
Another thing that I mentioned: even if you catch everything, there would
be some things that you couldn't do anymore.
Any method which throws notices or strict/deprecated notices or warnings
would be broken, as the execution would be halted (as the execution jumps
into the catch) which would be a major PITA to the userland developers, and
without further work, it could make the userland/engine in a more fragile
state, as the original call was interrupted but the execution still
continues from a different spot.
With the current error handling the execution either resumes after the
error handler is called, or the execution is terminates gracefully

The current error handling provides a way to trigger multiple
errors/warnings for an operation, and allows to still return and continue
the execution.
Turning everything into exceptions would kill both of those, and without
providing something similar suite, we can't do that imo.

So basically these are our boundaries:

   - Fatal errors can't be turned into Exceptions, but it was mentioned
   multiple times, that there are some fatals, which could be turned into
   E_RECOVERABLE_ERROR.
   - Most/all non-fatal errors could be safe to be turned into Exceptions
   as without explicit measures(try-catch) on the caller's side, it would
   still stop the execution.
   - Every other warning/notice/etc. which are just holds additional
   information but not indicating unsuccessful execution in itself cannot be
   turned into Exceptions.

I have a few ideas about how to proceed from here, but I need some time to
gather my thoughts.

   1. http://www.mail-archive.com/internals@lists.php.net/msg60043.html
   2. http://www.mail-archive.com/internals@lists.php.net/msg60054.html
   3. http://www.mail-archive.com/internals@lists.php.net/msg60056.html
   4. https://wiki.php.net/rfc/errors_as_exceptions
   5. https://wiki.php.net/rfc/enhanced_error_handling
   6. http://www.mail-archive.com/internals@lists.php.net/msg60060.html
   7. http://www.mail-archive.com/internals@lists.php.net/msg60063.html
   8. http://www.php.net/manual/en/errorfunc.constants.php
   9. http://www.mail-archive.com/internals@lists.php.net/msg60061.html
   10. http://www.mail-archive.com/internals@lists.php.net/msg60065.html

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] Re: Error handling brainstorming


On 03/08/12 21:55, Ferenc Kovacs wrote:

Andrew:
From your mails, it seems that you don't agree with Stan on turning 
everything but fatals into exceptions[9].
I'm really confused about that, as if we take away warnings (and by 
that logic everything else which is less serious than a warning) the 
we would only have the fatal errors (which we already discussed to not 
turn into exceptions and you also seemed to agree[10]), E_USER 
and E_RECOVERABLE_ERROR.

Is this what you propose?
Warnings aren't errors as such (IMO they are little more than 
glorified debugging print statements). Making them into exceptions would 
mean you'd have to catch them, whilst at the moment they are loud but 
harmless.
However, I think more serious errors should be exceptions. But perhaps 
in PHP 6, because obviously this would break a lot of things.


My opinion (and this is what I tried to explain to you) is that it is 
pretty common in the core and the bundled extensions to raise notices 
and warnings left and right, and still do something,
By that I thought you meant errors of the kind E_STRICT, not warnings. 
Misunderstanding.
If we would turn anything less serious than E_RECOVERABLE_ERROR (so 
any notice, deprecation notice, strict notice or warning)into an 
exception, that would be a huuge BC break.
Of course. I think they are something the current errors system should 
remain for. It should be for that kind of thing, but proper errors 
(you know, things going wrong, not warnings etc.) should be exceptions, 
I think.
Basically silecing errors through setting error_reporting level, 
custom error handlers or the @ operator would stop working, and one 
should put everything into a try-catch block to not have his code 
blown into his code constantly.
Another thing that I mentioned: even if you catch everything, there 
would be some things that you couldn't do anymore.
Any method which throws notices or strict/deprecated notices or 
warnings would be broken, as the execution would be halted (as the 
execution jumps into the catch) which would be a major PITA to the 
userland developers, and without further work, it could make the 
userland/engine in a more fragile state, as the original call was 
interrupted but the execution still continues from a different spot.
With the current error handling the execution either resumes after the 
error handler is called, or the execution is terminates gracefully


The current error handling provides a way to trigger multiple 
errors/warnings for an operation, and allows to still return and 
continue the execution.
Turning everything into exceptions would kill both of those, and 
without providing something similar suite, we can't do that imo.


So basically these are our boundaries:

  * Fatal errors can't be turned into Exceptions, but it was mentioned
multiple times, that there are some fatals, which could be turned
into E_RECOVERABLE_ERROR.

Truly fatal errors can't become exceptions. But some fatal errors 
shouldn't be fatal and are recoverable (and I think these should become 
exceptions).


  * Most/all non-fatal errors could be safe to be turned into
Exceptions as without explicit measures(try-catch) on the caller's
side, it would still stop the execution.
  * Every other warning/notice/etc. which are just holds additional
information but not indicating unsuccessful execution in itself
cannot be turned into Exceptions.

I have a few ideas about how to proceed from here, but I need some 
time to gather my thoughts.


 1. http://www.mail-archive.com/internals@lists.php.net/msg60043.html
 2. http://www.mail-archive.com/internals@lists.php.net/msg60054.html
 3. http://www.mail-archive.com/internals@lists.php.net/msg60056.html
 4. https://wiki.php.net/rfc/errors_as_exceptions
 5. https://wiki.php.net/rfc/enhanced_error_handling
 6. http://www.mail-archive.com/internals@lists.php.net/msg60060.html
 7. http://www.mail-archive.com/internals@lists.php.net/msg60063.html
 8. http://www.php.net/manual/en/errorfunc.constants.php
 9. http://www.mail-archive.com/internals@lists.php.net/msg60061.html
10. http://www.mail-archive.com/internals@lists.php.net/msg60065.html


To sum up my thoughts:
- real (i.e., things going wrong, code doing something bad) errors 
should become exceptions, with the possible exception of fatal errors 
that it is impossible to recover from
- notices, warnings, deprecations, etc. should stay as PHP errors, so 
you can just suppress them if you want, and they don't require you to 
handle them


So fatal errors and notices/warnings/deprecations stay errors, 
everything else becomes an exception.


Clear?

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu



--
Andrew Faulds
http://ajf.me/

[PHP-DEV] Re: Error handling brainstorming

On Fri, Aug 3, 2012 at 11:05 PM, Andrew Faulds a...@ajf.me wrote:

  On 03/08/12 21:55, Ferenc Kovacs wrote:

 Andrew:
 From your mails, it seems that you don't agree with Stan on turning
 everything but fatals into exceptions[9].
 I'm really confused about that, as if we take away warnings (and by that
 logic everything else which is less serious than a warning) the we would
 only have the fatal errors (which we already discussed to not turn into
 exceptions and you also seemed to agree[10]), E_USER
 and E_RECOVERABLE_ERROR.
 Is this what you propose?

 Warnings aren't errors as such (IMO they are little more than glorified
 debugging print statements). Making them into exceptions would mean you'd
 have to catch them, whilst at the moment they are loud but harmless.


errors and warnings/notices/etc. share the same infrastructure(called error
handling. :P) so it is a little bit easy to get confused when someone talks
about error handling in generals by errors, or only just a subset of the
error levels.


 However, I think more serious errors should be exceptions. But perhaps in
 PHP 6, because obviously this would break a lot of things.


okay, then it is clear.




  My opinion (and this is what I tried to explain to you) is that it is
 pretty common in the core and the bundled extensions to raise notices and
 warnings left and right, and still do something,

 By that I thought you meant errors of the kind E_STRICT, not warnings.
 Misunderstanding.


I was referring to notices/warnings, sorry for the confusion.
But it seems from your reply that you take E_STRICT messages as errors?
Why? Those can only happen on successful operations, and until 5.4, they
weren't part of E_ALL, so they are the less known and less serious of all
of the error levels.



  If we would turn anything less serious than E_RECOVERABLE_ERROR (so any
 notice, deprecation notice, strict notice or warning)into an exception,
 that would be a huuge BC break.

 Of course. I think they are something the current errors system should
 remain for. It should be for that kind of thing, but proper errors (you
 know, things going wrong, not warnings etc.) should be exceptions, I think.


Yeah, errors are meant to be explicit, hard to not notice/handle and for
that description, Exceptions works just fine.



  Basically silecing errors through setting error_reporting level, custom
 error handlers or the @ operator would stop working, and one should put
 everything into a try-catch block to not have his code blown into his code
 constantly.

  Another thing that I mentioned: even if you catch everything, there
 would be some things that you couldn't do anymore.
 Any method which throws notices or strict/deprecated notices or warnings
 would be broken, as the execution would be halted (as the execution jumps
 into the catch) which would be a major PITA to the userland developers, and
 without further work, it could make the userland/engine in a more fragile
 state, as the original call was interrupted but the execution still
 continues from a different spot.
 With the current error handling the execution either resumes after the
 error handler is called, or the execution is terminates gracefully

  The current error handling provides a way to trigger multiple
 errors/warnings for an operation, and allows to still return and continue
 the execution.
 Turning everything into exceptions would kill both of those, and without
 providing something similar suite, we can't do that imo.

  So basically these are our boundaries:

- Fatal errors can't be turned into Exceptions, but it was mentioned
multiple times, that there are some fatals, which could be turned into
E_RECOVERABLE_ERROR.

  Truly fatal errors can't become exceptions. But some fatal errors
 shouldn't be fatal and are recoverable (and I think these should become
 exceptions).


yeah, this is in line with what I said.

... skip the links ...

To sum up my thoughts:
 - real (i.e., things going wrong, code doing something bad) errors
 should become exceptions, with the possible exception of fatal errors that
 it is impossible to recover from


I think that is the further where can we go without breaking every code out
there.


 - notices, warnings, deprecations, etc. should stay as PHP errors, so you
 can just suppress them if you want, and they don't require you to handle
 them


I'm thinking about some kind of new infrastructure which would allow the
developer to handle/fetch the errors locally (similar to how you can fetch
the last error with error_get_last(), but with the ability to fetch
multiple items and only those which were generated for a given piece of
code.
of course we could still keep the set_error_handler() as I see two
different use case for handling warnings:

   1. you want to log all errors in some other format what the log_errors
   and error_log ini directives provide
   2. you want to get the errors/warnings in the same scope where the error
   occured and

Re: [PHP-DEV] [RFC] Remove calls with incompatible Context

On Mon, Jul 30, 2012 at 7:31 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:

 https://wiki.php.net/rfc/**incompat_ctxhttps://wiki.php.net/rfc/incompat_ctx

 An RFC for deprecating and removing $this from incompatible context.

 Comments are welcome.

 --
 Gustavo Lopes

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


for the record I got bitten by that once or twice in the past and first
time it was a huuuge wtf.
definitively a +1 from me.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Remove calls with incompatible Context

2012-08-03 Thread Etienne Kneuss

On Mon, Jul 30, 2012 at 7:31 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
 https://wiki.php.net/rfc/incompat_ctx

 An RFC for deprecating and removing $this from incompatible context.

 Comments are welcome.

4+ years ago Marcus already wanted to clean that up in PHP6.

Definitely +1.

Best,

 --
 Gustavo Lopes

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




-- 
Etienne Kneuss
http://www.colder.ch

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

Re: [PHP-DEV] [RFC] Remove calls with incompatible Context


On 03/08/12 23:36, Etienne Kneuss wrote:

On Mon, Jul 30, 2012 at 7:31 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:

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

An RFC for deprecating and removing $this from incompatible context.

Comments are welcome.

4+ years ago Marcus already wanted to clean that up in PHP6.

Definitely +1.

Best,

--
Gustavo Lopes

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





While we're at it,

$a = 'this';
$$a = new StdClass();

should be an error.
Also $GLOBALS['this'] = new StdClass();

https://bugs.php.net/bug.php?id=52428

--
Andrew Faulds
http://ajf.me/

Re: [PHP-DEV] Error handling brainstorming

2012-08-03 Thread Nikita Popov

On Fri, Aug 3, 2012 at 10:55 PM, Ferenc Kovacs tyr...@gmail.com wrote:
 Hi,

 We started a discussion about the current error handling mechanism and the
 possible improvements in the Why do disabled functions / classes generate
 a WARNING thread[1], but that is a little bit offtopic there, so I decided
 to create a separate thread for it.

I think there are several types of errors in PHP that have to be
handled differently:
 * There are debugging class errors, like notices etc. They are
normally programming mistakes, but don't really prevent further
execution of the script. Those should stay as they are. Throwing
exceptions here would make things more complicated for the caller.
 * There are real errors, which should actually stop execution, but
which currently don't because throwing a fatal error would be overkill
due to it's incatchability (and even recoverable fatals are hard to
catch). Many warnings fall into this category. E.g. if a function is
called with incorrect parameters (e.g. too little of them) then an
E_WARNING is thrown. The wrong function call is clearly an error, but
PHP chooses to continue execution there. In my eyes this is a mistake
and these cases should be exceptions. (As exceptions are easily
catchable one can combine the best of both worlds here).
 * There is a small number of recoverable fatal errors. Those are
obviously the clearest candidates for exceptions, because recoverable
fatal *is* basically an exception with very ugly catching.
 * There are a large number of fatal errors in places which aren't
really fatal. They probably should be recoverable fatals now, and as
such exceptions in the future.
 * There is a small number of truly fatal errors, i.e. some kind of
problem deep in the engine. There is probably no way to turn those
into exceptions.
 * Another special category are parse and compilations errors. Those
are not inherently fatal (e.g. a parse error in an eval() does not
have to stop script execution), but they would be really hard to turn
into exceptions with the current architecture.

To summarize, what I'd like to see:
 * Not-really fatal errors (and currently recoverable fatal errors) to
be converted into exceptions
 * Some of the warnings be converted to exceptions (depends on the
exact context).
 * Leave notices etc alone.

Nikita

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

Re: [PHP-DEV] Error handling brainstorming

When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo. 
My choice isn't based as much on what the current error severity is, or what 
the error severity is supposed to represent in general, because I've found 
in PHP often the error severity has no connection with the error that's 
being reported. So I decided this by observing the real-world errors that 
use a certain severity.


Many warnings and all E_STRICT errors clearly point to bugs in the code, 
wrong method signatures, non-existing variables and constants being used, 
which can easily do actual data damage if the script keeps running in 
undefined state (even if the engine is just fine with it).


PHP should not split the language semantic into loose, less loose and 
strict, there should be just one set of semantics: the PHP semantics, and 
when code does something that doesn't fit, it shouldn't be an ignorable 
warning.


I've found this speeds up the development process, keeps bug count down and 
protects the site/app's data in case of bugs.


Stan 



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

Re: [PHP-DEV] Error handling brainstorming

On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass sv_for...@fmethod.com wrote:

When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo.
My choice isn't based as much on what the current error severity is, or
what the error severity is supposed to represent in general, because I've
found in PHP often the error severity has no connection with the error
that's being reported. So I decided this by observing the real-world errors
that use a certain severity.

Many warnings and all E_STRICT errors clearly point to bugs in the code,
wrong method signatures, non-existing variables and constants being used,
which can easily do actual data damage if the script keeps running in
undefined state (even if the engine is just fine with it).

are you sure about that?
E_STRICT is more about code that works but relying on some quirk or
side-effect or simply does a stupid thing.
see http://www.mail-archive.com/internals@lists.php.net/msg24665.html about
the original proposal and the discussion and you can see the list of
E_STRICT errors in the 5.4 branch here:
http://lxr.php.net/search?q=E_STRICTdefs=refs=path=%28*c%29+OR+%28*h%29hist=project=PHP_5_4
stuff like using non-existing variables and constants are E_NOTICE, method
signature mismatches are either fatal errors or warnings AFAIR.

PHP should not split the language semantic into loose, less loose and
strict, there should be just one set of semantics: the PHP semantics, and
when code does something that doesn't fit, it shouldn't be an ignorable
warning.

it is the opposite, we allowed sloppy code in the past, and introduced
E_STRICT to allow the pedantic people to find and fix the quirks and
E_DEPRECATED for finding and migrating the code which will go away.
from all of the errors levels only E_DEPRECATED and E_STRICT is what means
that atm your code works as intended.
but for E_DEPRECATED it will not work in the future, and for E_STRICT it is
either does it's job sub optimally or the requested operation is just
stupid (but doable).
at least this is the theory, if you know something with doesn't in line
with this, we could talk about it. :)

I've found this speeds up the development process, keeps bug count down
and protects the site/app's data in case of bugs.

I agree that developing with E_ALL (including E_STRICT) is a good developer
mentality.
But I would find it too intrusive to start forcing everybody with the next
version to either fix every E_STRICT in their code, and even more weird if
we do that but still allow them to write code with full of E_WARNING and
E_NOTICE and get away with that.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Error handling brainstorming



  On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass sv_for...@fmethod.com wrote:

When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo. 
My choice isn't based as much on what the current error severity is, or what 
the error severity is supposed to represent in general, because I've found in 
PHP often the error severity has no connection with the error that's being 
reported. So I decided this by observing the real-world errors that use a 
certain severity.

Many warnings and all E_STRICT errors clearly point to bugs in the code, 
wrong method signatures, non-existing variables and constants being used, which 
can easily do actual data damage if the script keeps running in undefined state 
(even if the engine is just fine with it).



  are you sure about that?
  E_STRICT is more about code that works but relying on some quirk or 
side-effect or simply does a stupid thing.

Well think about it. Why is it a goal to let quirky/stide-effect/stupid code 
run? This almost always ends badly.

It also reduces compatibility between code libraries. I.e.:


  it is the opposite, we allowed sloppy code in the past, and introduced 
E_STRICT to allow the pedantic people to find and fix the quirks and 
E_DEPRECATED for finding and migrating the code which will go away.

If you use a well tested, popular library by sloppy coders who don't mind 
E_STRICT and E_NOTICE, but you're pedantic, what happens? You have to live 
with your error log filled with noise from the library or fork the library.

And when the sloppy coders miss bugs because they've decided the real PHP is 
about sloppy code that still works somehow, they miss bugs and then blame 
themselves or PHP for being a language that allows buggy code.

This is the end result if trying to turn PHP into everything for everybody. 
Instead, PHP should make up it's mind and stop littering the php.ini with 
semantics/behavior configuration for the language.

Have one behavior. Stick with it. Make it obvious.

Re: [PHP-DEV] Error handling brainstorming

On Sat, Aug 4, 2012 at 1:44 AM, Stan Vass sv_for...@fmethod.com wrote:

 **


 On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass sv_for...@fmethod.com wrote:

 When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a
 typo. My choice isn't based as much on what the current error severity is,
 or what the error severity is supposed to represent in general, because
 I've found in PHP often the error severity has no connection with the error
 that's being reported. So I decided this by observing the real-world errors
 that use a certain severity.

 Many warnings and all E_STRICT errors clearly point to bugs in the code,
 wrong method signatures, non-existing variables and constants being used,
 which can easily do actual data damage if the script keeps running in
 undefined state (even if the engine is just fine with it).


 are you sure about that?
 E_STRICT is more about code that works but relying on some quirk or
 side-effect or simply does a stupid thing.


 Well think about it. Why is it a goal to let quirky/stide-effect/stupid
 code run? This almost always ends badly.

 It also reduces compatibility between code libraries. I.e.:


my words aren't getting through to you.




  it is the opposite, we allowed sloppy code in the past, and introduced
 E_STRICT to allow the pedantic people to find and fix the quirks and
 E_DEPRECATED for finding and migrating the code which will go away.


 If you use a well tested, popular library by sloppy coders who don't
 mind E_STRICT and E_NOTICE, but you're pedantic, what happens? You have
 to live with your error log filled with noise from the library or fork the
 library.

 And when the sloppy coders miss bugs because they've decided the real
 PHP is about sloppy code that still works somehow, they miss bugs and then
 blame themselves or PHP for being a language that allows buggy code.

 This is the end result if trying to turn PHP into everything for
 everybody. Instead, PHP should make up it's mind and stop littering the
 php.ini with semantics/behavior configuration for the language.

 Have one behavior. Stick with it. Make it obvious.



if we turn E_STRICT to behave exactly as E_ERROR there is no point keeping
the E_STRICT level.
personally I disagree with turning something which was a pedantic notice in
one version into an unsupported feature which fatals out if you try to use
it in the next.
maybe E_STRICT-E_DEPRECATED-E_ERROR

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] [proposal+patch] Addition of ?() as shorthand for isset()


Hi!

I've always thought isset() was quite ugly. For something I use quite 
frequently for checking the existence of array keys, I feel it is too 
many keystrokes, and is ugly.


So, I decided I would create a shorthand for isset().

One option suggested was a new operator, 'expr ??', which I don't like 
the idea of very much. I would also have liked 'expr ?', but that would 
conflict with the ternary operator, 'expr ? expr : expr'. Then, I had 
the idea of '? expr', but that also caused a conflict. So I settled on 
'? ( expr )', which is used like this:


  if (?($_POST['credit_card_no'])) {
  // ...
  } else if (!?($_POST['use_paypal'])  ?($_POST['bank_acc_no'])) {
  // ...
  }

And since it doesn't break the ternary operator, like this:

  $number = ?($x)? intval($x) : 0;

I quite like how it combines with !, so !?() tests for non-existence, 
and ?() tests for existence.


It's quite trivial, but it would save me (and probably many others) 
time, and I think it would add some extra character to PHP, with its 
quirky syntax. :)


Patch attached. Thoughts welcome.

--
Andrew Faulds
http://ajf.me/

From 24107911374fd9e9dbc731b4564a440dd72f5568 Mon Sep 17 00:00:00 2001
From: Andrew Faulds a...@ajf.me
Date: Sat, 4 Aug 2012 01:37:23 +0100
Subject: [PATCH] Added ?() op as shorthand for isset() - Added ?() - Added
 test

---
 Zend/zend_language_parser.y |1 +
 tests/lang/shorthand_isset.phpt |   21 +
 2 files changed, 22 insertions(+)
 create mode 100644 tests/lang/shorthand_isset.phpt

diff --git a/Zend/zend_language_parser.y b/Zend/zend_language_parser.y
index c88e9a7..5781cd6 100644
--- a/Zend/zend_language_parser.y
+++ b/Zend/zend_language_parser.y
@@ -773,6 +773,7 @@ expr_without_variable:
 	|	'(' expr ')' 	{ $$ = $2; }
 	|	new_expr		{ $$ = $1; }
 	|	'(' new_expr ')' { $$ = $2; } instance_call { $$ = $5; }
+	|	'?' '(' isset_variables ')' { $$ = $3; }
 	|	expr '?' { zend_do_begin_qm_op($1, $2 TSRMLS_CC); }
 		expr ':' { zend_do_qm_true($4, $2, $5 TSRMLS_CC); }
 		expr	 { zend_do_qm_false($$, $7, $2, $5 TSRMLS_CC); }
diff --git a/tests/lang/shorthand_isset.phpt b/tests/lang/shorthand_isset.phpt
new file mode 100644
index 000..9218f89
--- /dev/null
+++ b/tests/lang/shorthand_isset.phpt
@@ -0,0 +1,21 @@
+--TEST--
+?() (Shorthand isset()) operator test
+--FILE--
+?php
+$arr = [];
+var_dump(?($arr['nonexistant']));
+var_dump(!?($arr['nonexistant']));
+
+$arr['hello'] = 7;
+var_dump(?($arr['hello']));
+var_dump(!?($arr['hello']));
+
+var_dump(?($arr['hello']) ? 'expected' : 'unexpected');
+var_dump(!?($arr['hello']) ? 'unexpected' : 'expected');
+--EXPECT--
+bool(false)
+bool(true)
+bool(true)
+bool(false)
+string(8) expected
+string(8) expected
-- 
1.7.9.5


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

[PHP-DEV] 回复： [PHP-DEV] [RFC] Remove calls with incompatible Context

2012-08-03 Thread Reeze Xia



在 2012年8月4日星期六，上午6:40，Andrew Faulds 写道：

 On 03/08/12 23:36, Etienne Kneuss wrote:
  On Mon, Jul 30, 2012 at 7:31 PM, Gustavo Lopes glo...@nebm.ist.utl.pt 
  (mailto:glo...@nebm.ist.utl.pt) wrote:
   https://wiki.php.net/rfc/incompat_ctx

   An RFC for deprecating and removing $this from incompatible context.

   Comments are welcome.
  4+ years ago Marcus already wanted to clean that up in PHP6.
   
  Definitely +1.
   
  Best,
   --
   Gustavo Lopes

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

   
   
  
 While we're at it,
  
 $a = 'this';
 $$a = new StdClass();
  
 should be an error.
 Also $GLOBALS['this'] = new StdClass();
  
 https://bugs.php.net/bug.php?id=52428
then so does: extract(array('this' = 'scalar')); and the similar situation 
that may import variables.

  
 --  
 Andrew Faulds
 http://ajf.me/

Re: [PHP-DEV] Error handling brainstorming