Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 11.11.2009, at 14:50, Greg Beaver wrote:
> stream_resolve_include_path() as currently constructed could not be
> intercepted, and is actually unable to process an include_path that
> contains streams. I'm guessing it was written long before PHP 5.3.
> This could be easily fixed by having stream_resolve_include_path call
> zend_resolve_path() instead of doing its own internal calculations.
> With these changes, an opcode cache could easily cache the results.
ok. sounds like something that should be done.
> As for your naming concerns, if we were to add an alias called
> is_includable() to stream_resolve_include_path(), that would be much
> clearer:
>
> if (is_includable($file)) {
>include $file;
> }
>
> The assumption here is that we are simply testing whether the file
> exists and whether php can actually read the file, not whether the file
> has syntax errors. A file with syntax errors is an exceptional
> situation, and should be handled by a clear fatal error, imo.
Well for all I care it could remain with stream_resolve_include_path(), though
I am not sure if we really need that "stream" namespace, then again its a
function that will not be used a lot in daily coding, so I do not care either
way.
I have updated the current RFC accordingly:
http://wiki.php.net/rfc/autoload_include
So there are three approaches listed in the RFC:
1) http://wiki.php.net/rfc/autoload_include#proposal
add a new alternative to include, which works the same except that for missing
files it returns null and on success it returns the file location (unless the
file already returns something else explicitly)
2) http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire
add stream support to include/require
3)
http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path
fix up stream_resolve_include_path() to support streams.
I would like to call for a vote on the above. For 1) and 3) I invite everybody
to optionally also submit a proposal for a name. Finally optionally include in
your vote if would like to see this feature added to 5.3.2 or if it should wait
for the next minor/major version update instead.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion about ternary operator
On 22.11.2009, at 03:13, D. Dante Lorenso wrote: > Lukas Kahwe Smith wrote: >> On 21.11.2009, at 22:29, Dante Lorenso wrote: >>> I would love to restate my recommendation for the function "filled". >>> Which is the opposite of "empty". Filled would accept a variable >>> number of arguments and return the first where empty evaluates as >>> false. >>> >>> Like empty, filled would not throw notices for undefined variables. >>> This is not the same as the ifsetor debate because filled is opposite >>> empty and cares not about isset. >> did you even read the RFC? > > Yes I did, and all I see is this in the References section: > > "Suggestion to leave an empty() variant out of the picture since > this feature can be implemented in userland, though this of > course not provide the full functionality of empty() which > does not trigger notices for missing variables" > > I didn't see my proposal listed in it anywhere. See this recommendation > from 3 1/2 years ago: > > - May 03, 2006 >http://www.mail-archive.com/internals@lists.php.net/msg21617.html Maybe I am then misunderstanding your proposal, as to me it is clearly covered and deemed not possible: http://wiki.php.net/rfc/ifsetor#rejected_features $var = ifsetor($var, $var2, "admin"); However this is currently not possible to be implemented without major slowdowns to the engine. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion about ternary operator
On 21.11.2009, at 22:29, Dante Lorenso wrote: > I would love to restate my recommendation for the function "filled". > Which is the opposite of "empty". Filled would accept a variable > number of arguments and return the first where empty evaluates as > false. > > Like empty, filled would not throw notices for undefined variables. > This is not the same as the ifsetor debate because filled is opposite > empty and cares not about isset. did you even read the RFC? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The inconsistencies/flaws of PHP5's object model
On 18.11.2009, at 09:23, Jingcheng Zhang wrote:
> Hello internals,
>
> I've just occured a syntax problem in the following script:
>
> class C {
>public $n = 1;
> }
> $o = new C();
> $o->f = function () use ($o) {
>echo $o->n;
> };
> $o->f();
> ?>
>
> The result of this script is "Fatal Error: Call to undefined method C::f()".
> I don't know this is the expected result. After trying more tests of
> adding/removing properties on the fly, I concluded these
> inconsistencies/flaws:
>
> 1. There is no way to add/remove instance-level members (both properties and
> methods) to class dynamically, but a way to add them to instance itself,
> which is a little buggy as above codes turns out;
> 2. There is no way to add/remove static members dynamically either;
> 3. There are __get(), __set(), __call() for instance-level members, and
> __callStatic() for static methods, but lacks __getStatic() and __setStatic()
> for static properties;
> 4. While using static class as object (general concept of "object", not
> "instance" here), it's extremly complex to simulate "prototype object", as
> static members simply do'not duplicate themselves at all while inheriting,
> therefore all of the child classes share a single static member of the
> parent class;
> 5. The inheritance rule of static member is not well documented, developers
> has to try it out themselves;
> 6. Static methods are allowed in interfaces, but not allowed in abstract
> class, which breaks the rule of abstraction;
> 7. An interface which has only static methods cannot ensure static methods
> in a class which implements it.
>
> Sorry to raise so many complaint, but these inconsistencies bring me a big
> headache when developing. I would like to hear the design rules of PHP5's
> object model, at least, the explanations of the above inconsistencies.
> Thanks very much!
>
It feels like a lot of these points have been raised before (especially in the
thread where the addition of closures where discussed). It would be nice if you
could turn this into an RFC, maybe digg a bit in the recent archives as well.
This would help to make it easier to find out why something wasnt done etc.
This helps in avoiding redundant discussions, but also helps people if after
all certain changes do become possible/feasible eventually.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP6's future
On 18.11.2009, at 02:24, Greg Beaver wrote: > What needs to happen is for developers to focus on finding problems > highlighted by failing .phpt tests. The most complex extension that > needs some loving is the SPL extension. I would hazard a guess that if > these .phpt tests are fixed, a large number of roadblocks will disappear. AFAIK PDO is also in a very broken state, though independently of PHP6 I am currently hoping to revitalize PDO development, which might also lead to building up the necessary resources/skills to get HEAD fixed up too. Anyways, to me it boils down to 2-3 people really putting in lots of time to move things forward and to build up momentum again. We all know how it feels to add stuff onto something that is fairly broken and who's future is not yet certain. We all hate wasting time, so those 2-3 people will mostly reassure that time spend on HEAD is not wasted. In this light when I last brought up this topic. Not sure if on IRC or the mailinglist it turned out that 3 different approaches were seen by people. Again who ever takes the helm on this will hopefully realign the community behind just one: 1) similar to Kalle's suggestion, clean up HEAD 2) make HEAD a proof of concept branch, turn 5_3 into HEAD, reimplement just the features we in the end found useful from HEAD 3) make HEAD a proof of concept branch, turn 5_3 into HEAD, implement a string class (both a unicode and a non unicode version) along the lines of the intl extension to bring unicode functionality to PHP but in a way that lets people easily switch between unicode aware strings. I think I remember that 2) got the least support. Ilia was the main one argueing in favor of 3) and Derick was very much pro 1). I am putting this out there not because I am looking forward to a lengthy discussion on this, but more because I feel that who ever takes on this task should know that there are different opinions on how to best proceed. In the end however I think that who ever does the work will probably get the biggest say in how things play out .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] suggestion about ternary operator
On 21.11.2009, at 06:12, Alban wrote:
> This is not a big problem but if a solution exists, this would be so
> cool ! Especialy when we have to check existance of twenty or more key in
> array. Code would be be lighter and clear.
> Since i use PHP, I always have in my 'common function file' a function
> like that :
>
> function getIssetVar($var, $default) { return ((isset($var)) ? $var :
> $default); }
>
> So is it possible to make a little improvement on this operator or
> introduce a new operator or a core function which do that ? What's your
> feeling about it ?
this feature request has already been discussed and declined:
http://wiki.php.net/rfc/ifsetor
please review this rfc before continuing this thread.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
On 12.11.2009, at 15:27, Ralph Schindler wrote: There is one key piece of information to keep in mind about this proposal. This is based on the assumption that all autoloaders need to do this type of include_path check. I (now) feel this is questionable concerning that particular use case. The best practice should be to only have autoloaders for a specific namespace, this would mostly solve the "is it there?" type of fopen/ include_path check. If NamespaceA registers an autoloader for itself, it should not try to resolve and load files from other Namespaces, for example NamespaceB. This idea is partially taken care of in the proposed SplClassLoader .. http://gist.github.com/221634 .. assuming the above best practice, a namespcae should know whether or not to try to include something inside it's own namespace, and if something is not there, an E_FATAL (or potentially an exception) is the best option when include does not work. I also have a question as to how the argument: throw=true comes into play in the current spl_autoload_register (does it affect this proposal too?) http://github.com/php/php-src/blob/PHP_5_3_1/ext/spl/php_spl.c#L422 ON THE OTHER HAND, I think it is important that we should be able to check for the existence of a relative to include_path location regardless of autoloading consequences, and that is what sara attempted with stream_resolve_include_path, even though I'm not fond of the name. your argument has some merit, however i think that the use case should still be supported. well even inside your own namespace it can be tricky to know the file name. for example in MDB2 i allowed the creation of modules. these could either be generic or rdbms dependent. since i did not want to have to maintain some registry that knows all modules (especially since modules can be added by users), i had to search for the right class name by seeing which file was available (either a directory with the module name and rdbms drivers as the php files .. or a generic php file). there might be other similar use cases, like having to deal with legacy code. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 11.11.2009, at 14:50, Greg Beaver wrote:
Lukas Kahwe Smith wrote:
On 11.11.2009, at 11:44, Mikko Koppanen wrote:
On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith
so a byte code cache should cache the resolution of the path thereby
speeding up the subsequent call to include?
stream_resolve_include_path() as currently constructed could not be
intercepted, and is actually unable to process an include_path that
contains streams. I'm guessing it was written long before PHP 5.3.
This could be easily fixed by having stream_resolve_include_path call
zend_resolve_path() instead of doing its own internal calculations.
With these changes, an opcode cache could easily cache the results.
ok.
As for your naming concerns, if we were to add an alias called
is_includable() to stream_resolve_include_path(), that would be much
clearer:
if (is_includable($file)) {
include $file;
}
The assumption here is that we are simply testing whether the file
exists and whether php can actually read the file, not whether the
file
Well I still maintain that is_includable() could imply for people that
no error can occur. Just like when calling is_int() means that it
really is an integer. so I still prefer "exists" or "resolve".
has syntax errors. A file with syntax errors is an exceptional
situation, and should be handled by a clear fatal error, imo.
well the error raised for a syntax error or missing file would not
change if we go in this direction.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 11.11.2009, at 11:44, Mikko Koppanen wrote:
On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith > wrote:
On 11.11.2009, at 01:50, Greg Beaver wrote:
if (can_include($file)) {
include $file;
}
I am sure you focused on the technical aspects. Just wanted to say
that for
a name "can" is not ideal, because there is no gurantee that the
file will
not have syntax errors. As such something with "exists" is better
(for
example include_file_exists(), though also not ideal) .. Stas
proposal of a
"file_find()" is also good, but I think it would be nice to have
"include"
in the name.
Isn't this what stream_resolve_include_path does?
it might .. the doc's are sort of unclear .. since fopen optionally
checks the include path. then again the name of the function implies
that it does a search in the include path. the name is a bit long ..
but i like the use of "resolve".
so a byte code cache should cache the resolution of the path thereby
speeding up the subsequent call to include?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 11.11.2009, at 01:50, Greg Beaver wrote:
if (can_include($file)) {
include $file;
}
I am sure you focused on the technical aspects. Just wanted to say
that for a name "can" is not ideal, because there is no gurantee that
the file will not have syntax errors. As such something with "exists"
is better (for example include_file_exists(), though also not
ideal) .. Stas proposal of a "file_find()" is also good, but I think
it would be nice to have "include" in the name.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 11.11.2009, at 10:47, Richard Quadling wrote: 2009/11/11 Lukas Kahwe Smith : [snip] Would using a userland-based set_error_handler() be of use here? If, under normal circumstances, blind include() is what is used, then trapping the error when it fails would be when you could test for whatever it is you want to test for? Well this makes it impossible to handle the issue locally, which creates all sorts of issues when you just want to drop in a frameworks autoloader. It also means that you now globally handle such failures, where you do not know if in case the file is missing there will be additional logic locally to handle the failure. Furthermore unless you use track errors you would not be able to determine if the load failed because of a missing file or a syntax error. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
Perhaps better would be to introduce a function:
if (can_include($file)) {
include $file;
}
opcode caches could easily snag this, as we could provide a simple
hook the way we do with stream_resolve_path(). That would actually
make a 0-stat smart autoloader a possibility. Just in case it isn't
obvious, can_include() would be the equivalent to an include_path
search followed by is_readable(), which is essentially what the fopen
() hack does now. can_include() would also remove the unnecessary
opening of the file that fopen() performs.
so you are suggesting that the byte code cache also cache file
searches performed by this function. this is starting to sound more
interesting from my pov.
regards
lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
On 10.11.2009, at 22:28, Stanislav Malyshev wrote: Hi! They dont want to determine if a file exists. They want to be able to handle the case of a missing file being included differently than a syntax error. Since php core does not provide such features, the only Let's see why they need to handle missing file being included differently? Or, even more interestingly - why they need to include file that is missing if they know they'd have to do something different? Maybe they would want to know if file exists or nor before trying to include it, because they don't know which exactly file they are going to include? The goal here, at least for ZF, is to find the right file and include it. Both APIs that I proposed allow to express it directly - find file and include it. Your API would make them do it through chain of trial and error by trying to include a string of non- existing files before actually trying a successful one, thus mixing three functions - finding files, including files and error reporting - into one. How it's better? Because its tons more efficient, requires less code from the end user and all the various other reasons i have stated before. Again we seem to have different priorities but reiterating them doesnt provide value for this mailinglist. So your points are taken, I will add them to the RFC. We will see if other people have an opinion and then someone might call for a vote. Now I also made it clear that its not about blindly silencing "errors" but there is a need to differentiate between different error causes. Of How you are going to differentiate? Your proposal only has one return value (null) which is conveniently coincides with return value that can be produced by include too by doing return;. You don't know why it failed, you don't even really know did it fail or not. You just know you got null in return. I stated the differences to include. As such I did not state that syntax errors should be handled differently, so in the case of a syntax error false would be returned and a warning raised. 1) checking before adds overhead and opens issue with potential race conditions I don't think it's real use case - please show me one framework that uses plugin includes through include path while other processes are deleting their plugins randomly. I think you are trying to solve non- existing problem here. Caching/templating APIs usually know exactly where their files are and don't need to look for them in include path. I never claimed that the race condition is a common scenario. Do note that I always called this an edge case, both on this list an in the RFC. The performance overhead however is real, both from additional function calls as well as additional filesystem access. 2) silencing the error and using track errors adds overhead and potential issues with custom error handlers Again, what frameworks need is to find the right file among variety of possibilities in include path and then include it. I think it can be well served by using existing "include" with addition of "find" API and there's no necessity for new language construct to serve one specific use case. In a month, some framework would have slightly different use case and you'd invent another packaged language construct for this? You are repeating yourself in the same email. You are not addressing 2) so just leave it out on your reply. To address your comment about if I am going to invent another construct. I have as well as other framework developers brought up this limitation in PHP for a while. You might have also noticed that this construct aka hack has been around for a while. So I am not trying to patch up the issues I discovered yesterday, I am trying to find a solution for a problem that has been know since years. As a result I do not share your concern that tomorrow we will need yet another different "magic" method to handle includes. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
On 10.11.2009, at 22:41, Alban wrote: I think if PHP throws exception instead of warning/error then this problem will not have existence reason : sure with exceptions we could provide more contextual information and also give a local way to handle the situation locally. that being said for now it was decided to only use exception for constructor errors in core php. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
On 10.11.2009, at 21:31, Stanislav Malyshev wrote: ok .. so your objection to the RFC is solely because it introduces a new language construct? No, my objection is that it is not necessary to introduce a language construct, and the construct introduced is not the right one. If frameworks want to find out if file exists or get its name - we should give them API to do that. If they want just to silence the errors - they already have the construct to do that. They dont want to determine if a file exists. They want to be able to handle the case of a missing file being included differently than a syntax error. Since php core does not provide such features, the only way to do this is using the fopen() hack, iterating over the include path .. or I guess track errors with @. My proposal actually makes it possible to do what the frameworks need with less overhead. There is no way to do what these frameworks need inside userland without the above mentioned hacks. The fact that almost all frameworks are forced to use these hacks and quite a significant number of developers use frameworks (resulting in quite a number of apps end users install also using these frameworks) implies that we are not talking about an edge case here. Now I also made it clear that its not about blindly silencing "errors" but there is a need to differentiate between different error causes. Of course having to use @ for such a common use case is also not ideal. Its just that the error handling we provide internally isnt really able to handle this scenario well: 1) checking before adds overhead and opens issue with potential race conditions 2) silencing the error and using track errors adds overhead and potential issues with custom error handlers Anyways, lets see if there are other comments in the coming days. I think you have made your priorities clear. At least I understand them, but do not share them. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
On 10.11.2009, at 20:38, Stanislav Malyshev wrote: there are many approaches to caching, one of which is delete to invalidate and regenerate before the next use. again as the RFC makes it clear .. the purpose is to be able to differentiate between a syntax error and a missing file. If you writing your own cache basing on includes, you can write sequence that handles deletion correctly, knows if your own data exist or not and doesn't need include path functions for that. sure .. but that requires yet more code. but in that case i might as More functionality requires more code. I think it's better than turning the language into kitchen sink of similar language constructs, each has a little tweak to suit one particular use case. Next thing we would have framework_include, database_include, template_system_include, my_personal_homepage_include and so on. I think we need to do very generic stuff in the language, less generic in functions and yet less generic - in user code. well imho neither require nor include have been written with the "right" API in mind to solve todays needs. for all i care we could also break BC for include and adjust it according to my proposal in PHP6. anyways .. you are glossing over several draw backs in the current possible approaches, each saying you can solve that in user land with more code. yet my proposal would be a tiny change in php core (probably alot of code could be shared) and would still surpass the user land approaches. i do not know if there is anything possible to make include itself more flexible since its a language construct and not a "normal" function. well iterate over the include path to be able to determine the absolute path and cache that, which is something i also want to enable in an efficient manner with the optional addition of returning the file loaded instead of true in case the file does not return anything explicitly. again something that i mentioned in the RFC. We could also have function file_find() (or any other name, let the bikeshedding begin) or something that would resolve filename against include path and return full name if such exists or false if none exists. That seems generic enough operation to have a function for. ok .. so your objection to the RFC is solely because it introduces a new language construct? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
On 10.11.2009, at 20:07, Stanislav Malyshev wrote: Hi! yes that would solve the issue partially. the race condition would still remain, but its admitedly a rare case .. well I guess not so rare if you I would have hard time thinking of application that deletes its own include files frequently from other processes and we are supposed to handle that deterministically. But even then worst thing would happen is that include fails. there are many approaches to caching, one of which is delete to invalidate and regenerate before the next use. again as the RFC makes it clear .. the purpose is to be able to differentiate between a syntax error and a missing file. (probably more used for some generated arrays and stuff like that). it would also not solve the imho needless file system operations. You could cache file_exists using all kinds of external caching mechanisms if you want to. sure .. but that requires yet more code. but in that case i might as well iterate over the include path to be able to determine the absolute path and cache that, which is something i also want to enable in an efficient manner with the optional addition of returning the file loaded instead of true in case the file does not return anything explicitly. again something that i mentioned in the RFC. that being said, i brought up adding such a flag to file_exists() a few times before and each attempt has been shot down saying that fopen() should have never gotten this flag and this portion of the code should not mess with the include path. Why fopen() should have never gotten this flag? I don't remember any argument on that. Also, if we have include path I see no reason why we shouldn't have code that can work with it. IIRC Derick was one of the most vocal against adding this to file_exists() and complaining about the fact that its even available for fopen(). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alternative to the fopen() hack in autoloaders
On 10.11.2009, at 19:49, Stanislav Malyshev wrote: Hi! In order to solve the above issues this RFC proposes the addition of a new construct/function for now called “autoload_include” for lack of a better name that largely behaves like the “include” does today with the following differences, that when the include failed because of a missing file no warning is raised and php null is returned. Maybe it'd be easier to just add parameter to file_exists that allows it to use include_path? I think that's at least what ZF is trying to do with that fopen - it tries to find out if such file exists in the path and if so - include it. I don't think you need to create special language construct for that - you can shut off warning with @. yes that would solve the issue partially. the race condition would still remain, but its admitedly a rare case .. well I guess not so rare if you have a busy site and try to implement some caching for generated files .. then again these kinds of files are rarely loaded via autoload (probably more used for some generated arrays and stuff like that). it would also not solve the imho needless file system operations. that being said, i brought up adding such a flag to file_exists() a few times before and each attempt has been shot down saying that fopen () should have never gotten this flag and this portion of the code should not mess with the include path. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders
On 10.11.2009, at 18:40, Mark Skilbeck wrote: What's the problem with file_exists() ? i have explained this in the RFC. for one it does not support the include path setting. furthermore this does not solve the race condition and requires more FS operations than my proposal would. regards Lukas
[PHP-DEV] alternative to the fopen() hack in autoloaders
Ahoi,
I have written an RFC for a more efficient solution to get rid of the
common fopen() hack inside autoloaders:
if ($fp = @fopen($file, 'r', true)) {
fclose($fp);
include $file;
}
Here is the gist of the proposal:
In order to solve the above issues this RFC proposes the addition of a
new construct/function for now called “autoload_include” for lack of a
better name that largely behaves like the “include” does today with
the following differences, that when the include failed because of a
missing file no warning is raised and php null is returned.
Further details can be found on the wiki:
http://wiki.php.net/rfc/autoload_include
As stated in the RFC, I am not happy with the name "autoload_include".
Suggestions welcome!
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regarding constructions like func()[0]
On 09.11.2009, at 18:46, jvlad wrote: I have filed a bug (suggestion) at http://bugs.php.net/bug.php?id=50003 What do you think about enabling such a constructions in future versions of php? On Nov 9, 2009, at 1:41 AM, David Zülke wrote: It's already on the list for PHP6: http://wiki.php.net/summits/pdmnotesmay09 (see Day 2, PHP 6, #13). No need to discuss this further, I think. You might also want to have that bug closed, it's redundant. There's also a declined-ish RFC on this matter: - http://wiki.php.net/rfc/functionarraydereferencing then I don't get the point. http://wiki.php.net/summits/pdmnotesmay09 last modified on 07/22/2009 while the "declinish" last modified on 02/05/2009 so the proposal is newer and doesn't say anything about status of the feature. It would be much easier to have ONE and only ONE issue for each feature planned or proposed for the future versions of php. Just a dedicated section at bugs.php.net site would work the best. At least much better than "declinish" stuff. you did read the disclaimer at the top of the pdm notes? anyways, an in person meeting of several php.net people does not constitute a decision. decision are made on this list. ideally they are based on an RFC that is then updated according to the discussions and decisions on this list. and even then decisions at times will be reversed too. so it goes. regards, Lukas Kahwe Smith m...@pooteeweet.org PS: I do however agree that in the future notes from meetings like this should be given a bit more details, like the date, the people who attended and stuff like that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
On 15.10.2009, at 19:40, Samuel ROZE wrote: Le jeudi 15 octobre 2009 à 11:08 +0200, Lukas Kahwe Smith a écrit : On 13.10.2009, at 10:34, Samuel ROZE wrote: http://wiki.php.net/rfc/pdonotices I assume that calling noticeInfo() will also purge all currently stored notices (maybe controllable via some parameter)? If purge all notices, without parameter, like errorInfo. For MySQL we would have to throw an error/exception in case there is a result set open on the same connection. Is it really impossible to query Database if there is another result set opened ? If there's a result set opened seems that there's another query in the same time with the same code ? Is it possible ? I don't think so... yeah .. thats just how it is in MySQL. the warnings are stored in the connection so even opening a second connection to be able to execute another query isnt going to help at all. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
On 13.10.2009, at 10:34, Samuel ROZE wrote: http://wiki.php.net/rfc/pdonotices I assume that calling noticeInfo() will also purge all currently stored notices (maybe controllable via some parameter)? For MySQL we would have to throw an error/exception in case there is a result set open on the same connection. I still believe that it makes sense to add this functionality. Without it we would have to add database specific solutions for various drivers. PostgreSQL being the obvious one, but even for MySQL it would make sense to then at least expose the warning count etc. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
On 14.10.2009, at 22:03, Stanislav Malyshev wrote: Hi! So lets warm this up again. HEAD is for development .. so lets get this into HEAD so that it will be part of the next bigger PHP release for sure! Well, the code is sitting here http://github.com/gron/php-src/tree/PHP_6-traits and waits to be merged. :) I thought before merging code it would be useful to have some discussion on if the code is actually doing what we want. If it's based on http://wiki.php.net/rfc/horizontalreuse then for example I can see some potential issues for bytecode caching related to renaming and changing visibility. Also, it is not clear that we want grafts there at all, some aspects of them seem to get too hairy, esp. $this issue or statics. i think Stefan is fully aware of that probably there will be a discussion first .. but i think we all agree that this feature is very high on the list of what people want and therefore i wanted to get this discussion going, so that after its concluded traits can be commited to HEAD. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
ead
than
typical forwarding cases. With respect to Traits, research has shown
that
conflicts occur only rarely and explicit handling of it is much less
overhead
and brings more power than trying to solve it implicitly.
Discussions
===
For the original Traits proposal a lot discussion has already taken
place.
The RFC_
summarizes the most important ones. Eventually, it resulted in an
additional
RFC-NBT_ proposing non-breakable Traits, which led finally to this
proposal.
The first thread on was started on the `mailing list`
(http://news.php.net/php.internals/35562) back in February 2008.
Grafts
--
PHP as a dynamic language would give the opportunity to work with this
grafts functionality more flexible, even without abstract method
definitions,
but this would be very unintuitive since the graft does not know it
is using
methods or properties from the grafted class. On the one hand this
would
even
break the notion of encapsulation and on the other hand, it would
cause
trouble
at least for properties because here it might be that the different
order of
method
execution results in unintended different results. Imagine something
simple
like::
value; }
public function set($value) { $this->value = $value; }
}
?>
Grafted into a class it would depend on the behavior of the grafted
class,
whether there is a property named value and thus the encapsulation is
broken.
Thus, it would be ambiguous to allow a forwarding from within a
grafted
class
to its grafting class for non-defined properties and methods.
Alternative Syntax Proposals
Different keywords and alternative syntaxes for traits have been
already
discussed on the `mailing list` and are documented more detailed in
the
original RFC_.
Some important proposals and new additional proposals are listed
below for
traits as well as grafts.
Traits
""""""
Assignment instead of ``instead``:
Keywords are a rare resource in any language. Thus, new keywords
should be
introduced carefully. To avoid the ``instead`` keyword, a notion of
assignment
was proposed. On the first look, it seems even to avoid an
impression of
renaming::
Grafts
""""""
Grafts use wildcard:
The proposed Grafts syntax is not DRY and all methods names to be made
available need to be enumerated. To avoid this enumeration, a syntax
with a
wildcard was proposed::
Links and Literature
.. _RFC: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html
.. _RFC-NBT: http://wiki.php.net/rfc/nonbreakabletraits
.. _agrarian cultivation:
http://www.robinsonlibrary.com/agriculture/plant/propagation/grafting.htm
.. _mailing list: http://marc.info/?l=php-internals&m=120336491008719
As already mentioned, Traits is not a totally new concept, but the
semantics
used in this proposal has been fully defined at first in 2003. For
scientific
information and papers about Traits
http://www.iam.unibe.ch/~scg/Research/Traits/
is a good starting point. Since it isn't a purely academic concepts,
there
are
already languages supporting Traits out there. Squeak, Perl6, Scala,
Slate,
Fortress and even for C#/Rotor implementation are available.
A detailed technical report has been published at
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca06bTOPLASTraits.pdf
It explains Traits and gives some formal proves about the soundness of
Traits, too.
Last but not least, in this PhD thesis
http://www.iam.unibe.ch/~scg/Archive/PhD/schaerli-phd.pdf
two case studies have been publish illustrating the benefits Traits
are
providing.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
DJ Suicide Dive
d...@ifnotwhynot.me
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On 12.10.2009, at 21:48, Joey Smith wrote:
Write yourself a bit of code that replaces ereg which could be
installed in an
auto_prepend location server-wide. Here's an example you could start
with,
although I should point out that I spent all of about 30 seconds
thinking about
it, so you might want to give it more thought than that - I'm sure
there are some
funny edge cases in the way people have relied on ereg behaviour,
but you'd be
more likely to know that than I since I haven't used ereg() since
the day PCRE
support was added to PHP.
if (! function_exists('ereg')) {
function ereg($pattern, $string, &$regs = array()) {
$matches = array();
$delimiters = array(chr(1),chr(1),chr(1),chr(1),chr(1),chr(1),'/',
'@', '#', '%', '_');
foreach($delimiters as $c) { if (strpos($string, $c) !== FALSE)
continue; $d = $c; }
if (preg_match_all($d.$pattern.$d, $string, $matches)) return
strlen($string);
return false;
}
}
Much the same could be done for split(), ereg_replace(), and so on.
Feel free to collaborate with the authors of PHP_Compat [1].
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
[1] http://pear.php.net/package/PHP_Compat
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On 12.10.2009, at 20:34, Tomas Kuliavas wrote: 2009.10.12 20:55 Carl P. Corliss rašė: Lukas Kahwe Smith wrote: [snip] On 12.10.2009, at 18:57, Mark Krenz wrote: On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye [pierre@gmail.com] said the following: [snip] But I'm willing to bet that the majority of people are using ereg, not PCRE. I've known about PCRE in PHP for a while now, but I continue to use ereg because I thought it had better support in PHP and that it was the more "official" function. Guess I was wrong. I'm sure I'm not the only one who thought this. Maybe try to substantiate that argument with a google code search or something. Personally I have seen quite the opposite, then again I have been actively encouraging people to use preg since about 5 or more years now. Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results Code Search of: "preg_(filter|grep|last_error|match_all|match|quote| replace_callback|replace|split)\( lang:php" shows ~374,000 results Looks like preg_* functions are used more often than ereg* functions to me... preg_quote() and preg_last_error() are support functions. They are used together with other pcre functions. You double some search results. If you have to support something, it is not about statistics. Even 1% is important. Before you use statistics against something, remember that statistics can be used against you too. Everyone of us is one in seven billion. Any person is just 0,00014% in Earth statistics. Puh, I think this was a valid attempt at putting things closer to numbers rather then assumptions. Mark's claim was that ereg is being used more than preg and I think these stats do put some doubt on that claim, even though it should also be noted that there are several ereg using functions that are not prefixed with ereg. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On 12.10.2009, at 19:47, Mark Krenz wrote: If ereg isn't ready yet then 6.0 should be delayed until it is ready. It probably never will be... That's bullshit. Its not like Duke Nukem or something. I've never seen a major version of PHP take more than a couple years to release and PHP 6 seems to be well on its way. I expected it would be released sometime in 2010. Uhm, please keep your language under control. Anyways PHP6 has been delayed quite a few times, which is why PHP 5.3 was released to get a lot of the PHP6 non unicode features into the hands of users earlier. Anyways if at all .. PHP6 will come out late 2010, but I think the first stable release will not come before 2011, meaning that there will be around 2 years between it being marked deprecated in a stable release and it disappearing in the latest stable release. Chances are high that the PHP5 tree will still be actively maintained for a few years there after and that the big libraries will not drop PHP5 support until a few years as well, so for most users they will have about 3-5 years to adapt. The rest are people who want to be on the bleeding edge and those users usually write their own code to be bleeding edge too. So relax and again if you feel that your paying customers will suffer too much, pay someone to write the code. Furthermore, if you care about PHP, you might want to register for a wiki account and write up that summary about this discussion, so that we can spare us starting this discussion at zero again in the future. Thanks and have a nice day. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On 12.10.2009, at 19:12, Pierre Joye wrote: Shorter version: Topics have been discussed to death, move on, nothing to see. actually in the spirit of how i documented the decision about ifsetor() [1] and the fact that contrary to "popular" opinion, the time of core devs is limited, it would be nice of someone would document the points raised by with "sides" about the deprecation of ereg in 5.3 and the removal in 6.0. regards, Lukas Kahwe Smith m...@pooteeweet.org [1] http://pooteeweet.org/blog/1200 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
On 12.10.2009, at 19:00, Samuel ROZE wrote: Hi, I'm writing here to take a point about the discussion. On one side, you want to turn this functionality to a global function, like it is describe into this patch and on the other side, you said that on MySQL and Oracle we can get this notices with queries so it is not needed for them but only for PostgreSQL. Before continuing every development I want to make like a survey about what I (or we) will do. Here are my proposals: 1. Make this functionality only for PostgreSQL, with a "pgGetNotices" function. 2. Continue development for MySQL & Oracle, with the known that if notices recuperation is enabled, PDO will have to do queries. 3. Let development at this stage waiting that somebody else propose a notices patch for other Database than PostgreSQL. Note: For MySQL there'is the mysql_info function (http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html) well .. what Pierre (and me supporting him) was asking for is to create an RFC page that details the actual sticking points with this feature so that they can then discuss the above points more if need be .. or we can take a vote on how to proceed. You are asking the general community to vote on something where there is no clear document describing the state of the discussion. Remember not everybody reads all messages and even I am likely to have forgotten a point raised in this thread by now .. and I have payed attention to this thread from the very beginning. Writing an RFC is not about making your life miserable .. and its not about stalling your request either. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Wow, you sure do assume a lot of things about PHP and its development community. I have never seen your name on this list before and (now I am assuming) do not know the state of development of PHP6 (as in that its more or less on halt until someone gets things going again). On 12.10.2009, at 18:57, Mark Krenz wrote: On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye [pierre@gmail.com ] said the following: The ereg functions cannot work with Unicode and can't be fixed without rewriting them. Nobody likes to do it as pcre works just fine and has many active maintainers (inside and outside php). But I'm willing to bet that the majority of people are using ereg, not PCRE. I've known about PCRE in PHP for a while now, but I continue to use ereg because I thought it had better support in PHP and that it was the more "official" function. Guess I was wrong. I'm sure I'm not the only one who thought this. Maybe try to substantiate that argument with a google code search or something. Personally I have seen quite the opposite, then again I have been actively encouraging people to use preg since about 5 or more years now. Again, this isn't a debate on which is better, I only want to STRONGLY stress that I think its a big mistake to remove it in 6.0. If you wanted to remove it in 6.0, you should have sent out the deprecated warning in the whole 5.0 series, not just 5.3, which most people don't even use. If nobody simply wants to do the work to make sure ereg is ready for PHP 6 and unicode support, then you are not doing your job. I hate to call it a job because I'm sure that you all enjoy doing PHP development, but there are times when you have to bite the bullet and do the hard work because its your responsibility to do so. Our job for the most of us is to convince our boss's that the time we spend on company time is a worthwhile investment. There are of course people who work on PHP for fun in their spare time .. not sure if job fits the description for stuff they want to do. Anyways, that doesnt mean that either of the two mentioned "groups" of developers isnt doing a lot of boring tedious work for PHP as it is. I feel like I shouldn't even have to tell you this, you develop a programming language that is known by millions and runs web apps that are used by the whole Internet. Well the whole internet hasnt setup a donation box to pay for developers to work on stuff like this full time. If ereg isn't ready yet then 6.0 should be delayed until it is ready. Somehow I doubt that you'd have trouble finding volunteers to do the work if they know what was at stake. There are probably a lot of people out there perhaps even on this list that would love to show off their chops by submitting some piece of code that will get them noticed. If those of you that have responded are not willing to do the work, then open it up for review by others. Send out a call for volunteers. Maybe my inquiry will spark some interest. Imagine being able to say that you were the one that saved the ereg function. Well again an assumption .. no we do not have enough developers to do all the cool things we can think up and still fix bugs, document stuff etc. Feel free to step up .. but it makes no sense to start a php.net plea for help to get something ported to PHP6, where we will have a perfectly fine alternative. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
On 12.10.2009, at 12:07, Pierre Joye wrote: hi, On Mon, Oct 12, 2009 at 11:58 AM, Matteo Beccati wrote: Given the recent posts, I'd vote to only add whatever is needed for the drivers to access the extra data. That means to only add the specific pgsql code to gather notices as the mysql and oracle drivers are already capable of fetching warnings/dbms_output. To me, this would be much clearer: a common interface to access different kind of data would definitely not be a step forward in terms of abstraction. I'd to vote for nothing right now as I can't vote while shooting in the dark :) In other words I do think that this addition is a right step in terms of abstraction (and is mostly a debugging feature too). However as it has been said during this discussion we have to be careful. The only to be sure about the right way to do it is to have an implementation for each driver and valid it. A little RFC can help to keep tracks of everything. I like to go ahead with the implementation and then see if it is a good thing or not, or if it is possible at all for all drivers. yeah .. it does seem like its trickier than i originally thought. moreover having a proper RFC will help document why we decided to add this feature (or not add), which can help for future similar discussion. the aim of the RFC is therefore to document the actual feature, the potential issues and the pro's and con's about having this inside PDO core. and of course links to proposed patches. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
On 11.10.2009, at 17:55, Daniel Convissor wrote: If the notice/warning gathering abstraction is going to be sending queries to the DBMS in the background, one needs to be careful about maintaining both the results and metadata from the original query that caused the warnings. hmm why do you think that PDO would need to take special care about this? seems like this is the job of the PDO using code .. but it does raise one concern that i did not think about before: one potential issue is that with unbuffered queries (which are on by default) in MySQL you can only have one open result set at a time, so you cant check the notices until you have fetched the result set .. then again notices are usually only for insert/delete/update .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
On 10.10.2009, at 19:32, Samuel ROZE wrote: Le samedi 10 octobre 2009 à 15:51 +0100, Lester Caine a écrit : Ferenc Kovacs wrote: Then see how we can do it for the other drivers at the same time. I'm looking for Oracle. Is somebody know how we can do for MySQL (and how raise notices with it) ? http://dev.mysql.com/doc/refman/5.1/en/show-warnings.html Something to consider here is that, like MySQL in this case, many of these types of activity ARE now available as SQL queries and so do not have to be handled specially by the driver. It is only those areas where the results are only available by non-SQL calls that should be added as special cases. PDO has no interest in mapping SQL between different engines! Carrying out additional SQL calls in the background to emulate functions required by other drivers just seems wrong? The Firebird engine has been working to move all of the 'service' facilities which would normally be handled directly by the driver into simple SQL queries to get around this problem from the other end. It is the case for MySQL and Oracle...so for your mind, we don't have to make this option available ? I disagree because PDO want make that PHP codes support many Databases and if I want to get this notices on MySQL, I can use "SHOW WARNING" but, if my apps is used on PostgreSQL, my query will fail ! If I can use PDO::noticeInfo in MySQL and in PostgreSQL, it will be great. :-) And we have to know that these additional requests will be executed only if PDO::ATTR_LOG_NOTICES is turned to 1 ! So user want them... ;-) i do agree that we need to choose wisely, where we abstract. furthermore PDO at least currently doesnt really aim to offer a complete solution for portability in the sense that it leaves out a lot of features that would be required to make apps portable on the SQL level. however i personally think this case seems legit enough to get handled. more importantly we have someone working out the necessary code and there is little chance if it having adverse effects on any existing stuff .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
On 07.10.2009, at 15:49, Matteo Beccati wrote: Pierre Joye ha scritto: On Wed, Oct 7, 2009 at 1:27 PM, Samuel ROZE wrote: This is a bit complicated and very different ! Actually, each database works as it want and it may be better to use different functions for each driver. That defeats the whole purpose of PDO. The meaning of each message will indeed different, but if one needs to call different APIs for each driver, I doubt anyone will ever use them. Quoting my chat with Rasmus in Verona earlier this year: "PDO is a database driver abstraction layer, not a database abstraction layer", or something along the lines, but I see your point ;) However, I've been thinking about this a bit more and I think that the different "message" meanings can be summarised like this: * MySQL raises warnings, esp. when not running in strict mode * Oracle uses them as a custom way to deliver messages/data * PostgreSQL being a bit of both worlds: informational + custom By all means, I like the idea of a unified "message" API, but do we really need the syntactic sugar (and development effort)? MySQL and Oracle drivers can already access them with a standard PDO::query() call. Only PgSQL notices require a special treatment because they are currently discarded. I guess this is becoming more philosophical question: is the base PDO class intended to only have common and portable functionalities and leve everything else to the drivers or should it also try and group other similar features to be more consistent even though not likely to be portable? Also I guess that mixing and matching names could be confusing: an experienced Oracle developer using "dbms_output" would hardly imagine that they can be fetched by calling getMessages() just by taking a quick look to the documentation. Same goes for a Postgres developer who can easily understand what pg_last_notice() does and would probably not associate the familiar notice concept with getMessages. yeah .. its certainly a valid question. we have stuff like lastInsertId(), which depending on the driver either gets the current value of a sequence or the last id generated for the connection. so going by that example unifying things under a common API makes sense if that means that it makes writing portable code easier. so if pgsql and mysql both give warnings that "paranoid" developers might want to interpret as an error whatever, then it seems to make sense to unify this under a common API .. so the key test is not to unify messaging API's but more unify things that are semantically similar. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
On 07.10.2009, at 08:09, Matteo Beccati wrote: Christopher Jones ha scritto: Could you use the new PG specific attribute to enable them but make them output/handled by the existing error/exception interface? That's what I originally thought. But there can be multiple notices triggered by a single query and they shouldn't make the query fail (i.e. throwing an exception would be awkward for a successful query). MySQL has similar notices. Like when stuff gets truncated etc. I also think that using the current "error modes" is probably not ideal. Or rather these arent exception worthy, and they should obviously not return false either. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Status PDO drivers in general
On 15.09.2009, at 09:04, Lester Caine wrote: I have no doubt that PDO works fine for many people, but since the limited target that it had was for data abstraction IS this actually achieved currently? Which drivers ARE fully functional, and what outstanding bugs remain on each? The list of bugs is long, the number of people looking after them and their time is small. This is a real problem. Some things are not easily wrapped without a lot of assumptions and limitations. PDO only tried to unify the really simple stuff but make it possible to t least do the complex. However blob/clob handling is a bit unwiedly in some ways (requiring the bind API and type parameters) it does make a few things nicer (mainly returning a stream). What is really needed is a wrapper like ADOdb that gets things under control, rather than every project creating their own implementation. This is the nice thing about ADOdb - it may be 'heavy' but it 'abstracts' the data in a way PDO seems unable to do. However it does make the code necessary to handle RDBMS differences a lot smaller, thought it of course does not compete with MDB2, Doctrine or ADOdb. Anyways it all boils down to having developers care. It mostly works for MySQL and SQLite I guess. PostgreSQL has seem some love recently. IBM seems to not care anymore. Oracle certainly doesnt. Microsoft never did. A really bad situation for such a core technology. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
On 28.08.2009, at 23:09, Stanislav Malyshev wrote: As I already noted, the masking - in most cases and definitely in recommended cases - would happen for errors that are NOT SEEN. Not reported. Not logged. Before the patch. Which means, whatever advantage you seek from looking at these errors, fixing them, reviewing the code, doing anything related to them at all, etc., etc. - you have ALREADY lost if when you decided not to report these errors. Without the patch. Before the patch. So all arguments about how wrong it is to disable errors when errors in fact might be useful are, again, irrelevant - they are already disabled without the patch. So far, the argument that made the most sense on this topic is that using this patch would taint you with "bad mojo", I guess because when you sacrifice some performance to the Gods of Unreported Errors, it's all OK, but without that sacrifice, they could become enraged and revenge you by... I don't know, giving you more bad mojo? Of course we are well aware that you can choose to ignore errors even today. However instead of adding yet another ini setting, some of us feel we should rather focus on solving the real issues. That certain errors in certain parts of your code are unavoidable and known and that certain pieces of code will raise errors to the global error handler even though you have all the code in place to handle the issue locally. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
On 28.08.2009, at 22:47, Richard Lynch wrote: I must say, however, that buried in Stas' use case, 3rd party, not-so-clean code, and realistic pragmatic installs thereof, is buried the rather large problem: Many people who do such a thing, do not really do a serious code-review of the 3rd party code. Right and even so .. why should using that 3rd party code make it sensible to flip this switch on everything? I am not really suggesting the following because I havent thought it out .. just an example of out of the box thinking we need in order to try and really address the root causes. Maybe we rather need some way to define error handling on a per directory basis. This way you could just mark this 3rd party lib to use a different error reporting mode. Maybe this could be expanded even more to also cover the ever increasing number of extensions that optionally throw exceptions. This way we might even be able to reconcile the issue that if you run PDO and one lib wants exception mode and the other doesnt, you need two PDO instances. Another, again not fully thought out approach, would be to do something along the lines of exceptions. A magic object which can carry some more context but still returns true on a === false check. This object would of course have to be super lightweight and it should just contain the necessary bits in order to be able to generate the full error message if needed. I guess that would still probably not solve the performance "issue" that Stas is trying to solve, since its hard to imagine that such a solution would not come with so much overhead that it speed up anything. However it might provide for a better solution to deal with providing error context information without forcing everybody to deal with try/catch. Anyways, so yeah I am squarely in the camp that believes that adding more tools to just forget about error reporting is bad mojo. I also very much agree that many functions do not use the right reporting level and that several functions could probably be made to make it easier to avoid those reports to begin with, though yes there are cases where there is simply no way to avoid them. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [patch] error masks
On 25.08.2009, at 00:54, Greg Beaver wrote: 1) if a tree falls in the forest and there is no one there to hear it, do we still have to put up with the performance loss? 2) as long as the patch does not break any backwards compatibility (error logging still works as it always did independent of error_mask, user error handlers still get the same stuff), why would we care? There is a time and place for being academic about fixing things and it is called development, not production. If you have bugs in production, you sure as hell want to know about .. and encouraging people to ignore them is a recipe for disaster. Stats "@fopen()" example is perfect here, so lets say we do add this feature and people simply turn of error's entirely so that they can instead write "fopen()", they feel all good about themselves, since they handle the error locally and get a magical speed boost (noticeable or not) .. all the while they are ignoring all sorts of E_NOTICES that would indicate them that they have some serious security issues. Again, I am all for being able to totally ignore E_STRICT/E_DEPRECATED in production .. but there is a time for fixing E_NOTICES .. and that time is always! regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
On 25.08.2009, at 00:12, Stanislav Malyshev wrote:
Hi!
Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED,
E_NOTICE, whatever, all cause a performance hit even if the
error_reporting level is such that they will never show up anywhere.
That's what this patch is trying to address. To write optimal code,
they have to be entirely clean of all messages including E_DEPRECATED
and E_STRICT.
BTW "cleaning the messages" won't help with performance problems in
many cases. Let's suppose you have a code that tries to open some
file and if it exists, do stuff (and if it doesn't it doesn't care):
$fp = @fopen($filename, "r");
if($fp) {
// do stuff
}
Now if you "clean" it, you do something like:
if(is_readable($filename)) {
$fp = fopen($filename, "r");
// do stuff
}
(and if you don't want race condition there, you still need the
if()). Then is_readable and fopen can still can't be guaranteed to
not produce warnings if there are open_basedir restrictions or
streams involved or FS could change in the meanitime. But now
instead of one FS access, you have two - not much of a speedup.
right .. but it should reduce the chances of such errors occurring.
and like i said .. that is obviously not a speed up, but a slow down.
but i generally think its wise to encourage people to properly avoid
error conditions locally, because otherwise sooner rather than later
you will also no longer see the error conditions which you did not try
to avoid/handle locally.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
On 24.08.2009, at 23:59, Rasmus Lerdorf wrote: Lukas Kahwe Smith wrote: On 24.08.2009, at 23:42, Stanislav Malyshev wrote: Hi! Quite boring to read this thread where two persons argue about something abstract. Stas, can you give a real life example where your patch is necessary..? Any code where you either use @ or error_reporting which is not -1 would benefit from it by not processing errors that go nowhere. I just looked at Zend Framework - with is pretty clean with regard to E_NOTICE/E_STRICT problems - and @ is used in dozens of classes around. The speedup would be probably not very big for whole RL application, but it's a 10-line patch, and little things help too. well a few of those places would probably be fixable, by providing functions to check beforehand if calling the final function would cause an error. but that if course would add more overhead, but would still be the "cleaner" solution. overall i am not so convinced about the ignoring approach. as for E_STRICT .. that shouldnt become less of an issue now that we have E_DEPRECATED .. but i guess that just means that in the future people will complain about E_DEPRECATED .. anyways to me both E_STRICT and E_DEPRECATED are development tools that can be totally ignored in production. however E_NOTICE should not occur in production and we shouldnt encourage people to make them disappear entirely. Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED, E_NOTICE, whatever, all cause a performance hit even if the error_reporting level is such that they will never show up anywhere. That's what this patch is trying to address. To write optimal code, they have to be entirely clean of all messages including E_DEPRECATED and E_STRICT. right .. what i was trying to say was that i can see value in being able to hide E_DEPRECATED and E_STRICT, but the error stuff shouldnt be hidden that way. users should either display or log their E_NOTICES and fix them! regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
On 24.08.2009, at 23:42, Stanislav Malyshev wrote: Hi! Quite boring to read this thread where two persons argue about something abstract. Stas, can you give a real life example where your patch is necessary..? Any code where you either use @ or error_reporting which is not -1 would benefit from it by not processing errors that go nowhere. I just looked at Zend Framework - with is pretty clean with regard to E_NOTICE/E_STRICT problems - and @ is used in dozens of classes around. The speedup would be probably not very big for whole RL application, but it's a 10-line patch, and little things help too. well a few of those places would probably be fixable, by providing functions to check beforehand if calling the final function would cause an error. but that if course would add more overhead, but would still be the "cleaner" solution. overall i am not so convinced about the ignoring approach. as for E_STRICT .. that shouldnt become less of an issue now that we have E_DEPRECATED .. but i guess that just means that in the future people will complain about E_DEPRECATED .. anyways to me both E_STRICT and E_DEPRECATED are development tools that can be totally ignored in production. however E_NOTICE should not occur in production and we shouldnt encourage people to make them disappear entirely. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dbase extension
On 20.08.2009, at 07:39, Joey Smith wrote: I know - dbase. Why is anyone still trying to use this? However, I thought it worth noting tha tthe extension is documented as "moved to PECL", but it doesn't appear to be there - at least, I couldn't find it at pecl.php.net/dbase or via the search form at pecl.php.net the sources have been moved out of core and into the pecl repo. however nobody made a release or even registered the extension on the pecl site. this is the case with a few other extensions. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt
On 28.07.2009, at 01:38, Takeshi Abe wrote: Hi, On Mon, 27 Jul 2009 18:44:20 -0400, Gwynne Raskind > wrote: README.SVN-RULES says 1. All changes should first go to trunk and then get merged from trunk (aka MFH'ed) to all other relevant branches. which I've been following so far. That document is outdated. It's now (strongly) preferred that you use one of the various methods for multi-branch commits available in SVN, using merge or a sparse checkout. Yes, I agree svn merge will work well. IIRC, though, it involves a leading commit for trunk (usually, or sometimes for some branch whatever) and then merged ones for other branches. Are such sereval commits OK? I think so yes. However I think we should standardize on one approach: svnmerge only makes sense if everybody uses it. Personally I favor the svnmerge approach if this also enables us to more easily setup a temporary RM maintained branch ahead of a release to prevent commit freeze periods. For extensions we can of course leave it to the extension maintainer, however there is no way to ensure that people are aware of what merging approach is used in the given extension, so this is also not really feasible. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Replacing errors with Exceptions
On 24.07.2009, at 16:06, Ben Scholzen 'DASPRiD' wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kalle Sommer Nielsen wrote:
Then ZF should provide an error handler that can be called inside the
user's error handler or simply choose to not use error handlers if
the
user have a custom error handler. I can't really see why the whole
language should change into using exceptions by default because of
something like this?
This second suggested solution doesn't change the current behaviour at
all, just adds an additional one, which under usual circumstances will
never appear.
Again, say for example, you have the following code:
- --
$fp = @fopen(...);
if (!$fp) {
// !some! error occured, handle it
}
- --
I already described the problems with this in the RFC, e.g. you don't
know, which error occurded, just that fopen failed. What a library
currently would have to do is:
- --
function exception_error_handler($errno, $errstr, $errfile,
$errline ) {
throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler('exception_error_handler');
try {
$fp = fopen(…);
} catch (ErrorException $e) {
// Handle the exception
}
restore_error_handler();
- --
One could surely do that, yet it is not only unneccesary much
additional
code, but also introduces overhead by setting and restoring the error
handler again and again.
Well this RFC suggests using Exceptions as a solution to a well known
problem:
In many places you cannot really handle different error conditions
well, because you cannot differentiate between different error
conditions (did that include fail because of a parse error or because
the file is missing?) or because you are passing data to a function
who's job is to validate and handle the data (simplexml example).
Currently the only solution is to enable track errors and the shut up
operator. Obviously that sucks.
Generally we have decided to leave Exceptions out of core with a few
"exceptions":
1) errors in the constructor will throw an exception
2) extensions may choose to offer an Exception mode (see PDO)
I never understood why we did 1), if a constructor can fail, then a
factory should be used instead. But oh well. With 2) you are obviously
also opening a pandoras box, that is similar to using a global error
handler that turns all Notices, Warnings etc as Exception: you can
easily break code that calls various libraries .. take for example
passing in a PDO instance to one library which expects the normal
error mode and another one that enables the Exception mode. For the
most part however we can conclude that most libraries enable the
Exception mode in PDO and I think you will be hard pressed to find any
PDO code example that doesn't assume that the Exception mode is enabled.
So does that mean its time to open the flood gates? Contrary to what
the RFC states, Exceptions are not the one error handling mechanism to
rule them all. They should be used for exceptional cases, but for the
most part functions/methods do fine with just returning false. Thats
all people need to know most of the time.
The issue is when there isn't just one possible error condition but
many and as a result you want to do different things based on which
ever error condition occurred. So lets take the include example.
Obviously when using include, you accept the case that the file is
missing (is not readable .. not quite the same, but probably the same
for the purpose of this example), otherwise require would have been
used. So returning false in that case makes sense. However and here we
do not have an answer yet, what should be returned when the file
exists but has a parse error? This I would call an exceptional case,
but are these cases sufficiently relevant so that we should force
Exceptions upon our general userbase?
One alternative approach would be to ensure that there are simply
proper validation functions, that take the guess work out of the error
condition. Like for ages people have been asking to make file_exists()
able to work with the include path. In the same vain, a method for
validating an xml file could be provided. The issue is here of course
that in both of these examples, doing the validation incurs
significant overhead (more so in the xml case), so doing the
validation beforehand would adversely affect performance (nevermind
the possibility of race conditions further complicating things). So
one approach would be to use the shut up operator and only call the
validation method afterwards to determine the exact cause of the issue.
Anyways, just pondering .. I do not really have a good solution, just
trying to define the problem at hand a bit more and the some of
options on the table.
re
Re: [PHP-DEV] better management of php-src/pear and PEAR's future in php
On 18.07.2009, at 01:01, Matteo Beccati wrote: Greg Beaver ha scritto: Matteo Beccati wrote: Not really: it will copy the link, not its content. At least that was my experience when I managing releases for an internal project using externals. What I usually did was to change the externals property to point to a specific revision, e.g. Property svn:externals set to foo -r33165 https://svn.example.com/bar Depending on the process it can either be done in the branch before tagging or on the tag itself. As a result exporting a tag will consistently retrieve the same version of the external resource even years after packaging. This sounds easy to forget - is it possible to script this? Not sure how packaging currently works, but I'm pretty sure it is possible to extend whatever we currently have to create an svn tag and do the required changes before exporting for packaging. If needed I can help with it once the whole process is defined. err .. of course you need to either point to a specific revision .. or better yet to a tag. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] svn checkout suggestion
On 17.07.2009, at 19:40, Jeff Griffiths wrote: On 17/07/09 8:31 AM, Davey Shafik wrote: ... More importantly, the branch/merge support in SVN is limited to temporary feature/bug branches. You branch, *complete* the feature/ bug fix, and then merge it in. After that, if you decide to carry on in your branch, SVN's merge tracking cannot handle the tracking of changes. You need to merge, delete, re-branch, carry on. This doesn't work for say, the 5.3.x branch fixes getting pushed into trunk, the 5.3.x branch is toast as far as SVN is concerned once you merge the first fix — quite useless. Is it that limited? I hadn't used it ( for a variety of reasons the server is stuck on SVN 1.4 or something ). We DO use the svnmerge tool for maintaining dev / stage / production branches for web apps and versioned branches of things like Komodo. I guess I had assumed form shire's reply that the svn 1.5.x merge support was a work- alike, but I haven't ever attempted to use it myself. there is a fat warning fo this in the manual. i dont quite get why . but that is the case atm. also using merge tracking is only fun if everybody does it .. because if only some people use it .. they first have to figure out which things have not been merged via svn merge, as svn merge updates its metadata. when merging you can either mark an entire range of versisions as merged .. or just individually. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] better management of php-src/pear and PEAR's future in php
On 17.07.2009, at 03:04, Johannes Schlüter wrote: On Thu, 2009-07-16 at 18:20 -0500, Greg Beaver wrote: I'd like to consider instead using svn:externals to pull in PEAR stuff directly from a STABLE branch from somewhere in the pear/ hierarchy. This would allow us over at PEAR to push the installation phars into that branch at the same time a release is made, and would also allow quick fixes by a quick revert to a previous revision. How does this work with tagging or releases? Currently the phar thing isn't tagged at all when building PHP releases, but I assume the svn:externals would be copied as is and might lead to wrong assumptions (like that a newer version was included) meaning we make the tagging more complex or avoiding confusion. if you svn copy .. it will copy the externals .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 10.07.2009, at 19:58, Stanislav Malyshev wrote: Hi! right .. lets not forget the original goal (though it hasnt been perfectly defined) the idea was to move common validation code out of the function body to > reduce code, increase readability and enable IDE's to be even smarter. I think while intent is good (avoiding repetitive code) the strict implementation would do exactly the opposite of what should be done - it would move the repeated validation from library code to client code. WHich would negatively influence both readability (in case you do it right) and code robustness (in case you forget to do the necessary checks). +1 ... this is one of the key points i tried to make in my RFC. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 10.07.2009, at 17:16, Alain Williams wrote: On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote: Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit And Exception is better than an Error because this give one chance to programmer for resolving the problem before program be halted. Not everyone understands try/catch. Perhaps a user supplied function_argument_error() could be called if not in a try/catch block. well we have an recoverable error in this case which is what you are asking for. an exception could be more useful since you can handle it locally and are not forced to handle this inside a global error handler. then again we really wanted to keep internal exceptio. throwing to a minimum. regardgs lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful than just calling the is_numeric method in the function body.
Plus
there's no longer the advantage of optimisers knowing the data-type.
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function body
to reduce code, increase readability and enable IDE's to be even
smarter.
moving the function body into the signature was not the plan, as it
will kill the above features for the sake of flexibility.
the point is not flexibility, its finding a sensible common
denominator for validation of input parameters and optimizing the
syntax for that case.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] one RM to rule them all
Aloha, FYI: Since 5.3.0 is out and we are now in maintenance mode for this branch, there is not really a need for a release manager in the strict meaning of the "title". In other words we can now go back to the traditional model of having a single RM that is mostly busy with technical decisions. As such I am stepping down to avoid the confusion that people keep thinking of me as someone who can actually review patches. I will of course continue to do my best to track todo items for the various branches. Go Johannes! :) regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 09.07.2009, at 10:39, Paul Biggar wrote: I think we can take Lukas's RFC and either change it or write something based on it for weak typing only. If people here find it useful I'll go ahead and do that. I believe people don't want this. I wrote a set of rules, Lukas wrote the RFC, and neither got anything like the support that strict typing got. Actually, in terms of weak typing we are now at 4 supporters of the general idea: Paul B., Lukas, Zeev, Christian S. Still a minority compared to the +1 votes for Ilia's strict typing proposal. Though it could be argued that a fair number only voted for the expansion of type hinting to scalar datatypes and did not really look into the entire strict vs. weak hinting stuff. regards Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 09.07.2009, at 12:49, Dennis Haarbrink wrote: I'm a framework developer and I have great interest in type hinting/ casting. I'm all for clarity and strictness, but it should definitely be a choice. PHP is known for its easy learning curve, that is one of its big powers and that should remain unchanged. But the way I see it is that it can be implemented without *requiring* you to use it, if you want to use type hinting/casting go ahead, if you don't want it, well, leave that bit alone. If it comes with a minor performance hit, OK, i can live with that, I agree with Lukas in that aspect, you don't spend lots of time checking/ casting anyway. As for hinting/casting would not be 'php-ish', i don't see it that way, i look at php as a language of possibilities, not restrictions. I think you misunderstood Zeev. He wasn't saying that this feature is not PHP-ish, he was specifically talking about "strict" type checking. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
On 09.07.2009, at 13:10, Patrick ALLAERT wrote: 2009/7/9 Zeev Suraski : Two other issues that we need to revisit: 1. Agree on when it will be implemented - I think it's pretty clear it should not go to 5.3. What would be the impact including this feature (once it is *technically* fine for everybody) in 5.3 code with #ifdef's so that this feature is enabled only at ./configure time and disabled by default. We could then imagine to switch this configure parameter as enabled by default in a future (major) release. This way, every vanilla PHP installation wouldn't suffer of BC problems while still providing the feature to a restricted set of users. thats a no go, since this would lead to incompatible PHP code. we have had various php.ini settings that have caused this and we do not want to pile onto this. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On 09.07.2009, at 02:28, troels knak-nielsen wrote: On Thu, Jul 9, 2009 at 2:15 AM, Mark wrote: I personally would be highly in favor of adding type hinting/casting BUT with the benifit that php actually becomes faster if you do things like that. Afterall you can use way more effective c code if you know what you expect right? As for the version to include type I sure hope that all the people in favour of this change aren't basing their opinion on some delusion that it would improve performance in any way. well .. this will have an effect on performance. for one the additional checks will probably add a small overhead for all users. the reduction in user land type check code should of course improve performance. that being said, none of the above will have a significant relevant affect on performance in real world applications (which usually spend most of their time talking to data stores and not type checking). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On 08.07.2009, at 10:25, Paul Biggar wrote: - wait for Lukas to finish what he's doing - new vote, more options (5.3.x/5.4/6.0, Lukas'/yours, make it clear what we're voting for) Do not wait for me. I have decided it doesn't make sense for me to write this RFC. There was essentially nobody that even agreed with the basic principle and I do not think I have what it takes to convince people otherwise. I would very much appreciate it if someone who has just been lurking for now, to pick up my RFC and improve it so that people do understand what I was trying to say. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On 07.07.2009, at 20:04, Paul Biggar wrote: Of course I am also quite opposed to sticking this into 5.3. On which grounds? If you don't like the feature, please cast a -1 That adding language syntax sugar anything but a major or minor release is a bad idea. And this even if Ilia does manage to solve the BC issues. If there are BC issues, we shouldnt even have to talk about 5.3 for one second. vote. If its because of the BC problems, I believe you and Johannes have veto power on what goes into 5.3.x? If so, do you intend to use it? I dont think we have a veto power, nor would I want to use it if we did have one. One job is to keep things focused and appeal to the general sanity if we feel that things are going off track. I would want to appeal to the general sanity on this one though :) regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Hi,
I am -1 on the inclusion of cast support. IMHO this part isnt thought
out and was just thrown in to silence those who feel that there is a
use case for non strict type hinting. But in that case I might as well
leave the type cast in the API calling code. The number of characters
saved are next to nothing, the performance impact is probably also
fairly irrelevant and with this syntax I get slapped and then I can
choose if I want to cast manually or do something else. But just
hiding things by just blindly casting seems counter productive (which
is why I proposed to add reasonable checks before doing the cast in my
RFC that would make things more compatible with data coming out of a
database, config file or other trusted data source). I just do not see
what is gained at all from:
A) foo((int)$bar);
function bar(int $bar) {}
vs.
B) foo($bar);
function bar((int) $bar) {}
What am I really saying with B)?
I don't care what you give me, I am going to use it as an int anyways?
IMHO no need to introduce a special syntax for this.
Of course I am also quite opposed to sticking this into 5.3.
Finally I would like to ask to rename this entire feature (including
what we currently already have) to "type checking" or something other
than "hint" in the documentation.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
On 07.07.2009, at 16:15, Stan Vassilev wrote: +1 if the object type hint is change to use T_CLASS so we don't break every external package using "Object" as a base class. http://www.google.com/codesearch?as_q=class\s%2Bobject&btnG=Search + Code &hl = en &as_lang = php &as_license_restrict=i&as_license=&as_package=&as_filename=&as_case= Greg Or this can wait until 6.0, when (as I hear) we'll have case- sensitive class names, so Object/object, Int/int won't cause collisions. I'm really puzzled why a non-essential, and for the past months (years?) controversial and always rejected feature such as strict type hints, has everyone turning 180 degrees and putting it in a minor release in the course of a week. amen to that. regards Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On 07.07.2009, at 00:55, Paul Biggar wrote: Hi Lukas, On Mon, Jul 6, 2009 at 11:03 PM, Lukas Kahwe Smith wrote: Ok, I have updated the RFC now with a table that shows that I expect to pass and fail. Its fairly late, so I might have missed something. In general what I am proposing is more lax than is_*() for the most part. Especially when it comes to checking strings. I hope you have missed some things (or that they are typos) because otherwise a good chunk of this is plain lunacy. Thank you for taking the time to review this. I am feeling kinda rushed here (I guess Ilia's call for votes proofs me right .. and apparently wrong at the same time). value string float int numeric scalar bool array 0 (integer) fail fail pass pass pass pass fail 1 (integer) fail pass pass pass pass pass fail 0 fails conversion to a float, but 1 and 12 succeed? fixed. 12 (double) fail pass pass pass pass fail fail It may seem that this is a good idea (12.0 passing the int check), but what if 12.0 is OK, but 144.0/12 does not (which might not be 12.0 due to floating point error)? right .. and the use case of this coming out of a config file is non existant. so that leaves the potentially slowly emerging use case of this coming out of a database and in this case people should just use the numeric check. '0' (string) pass fail fail pass pass pass fail '1' (string) pass fail fail pass pass pass fail I presume you see the '0'/'1' pass as bools as lunacy. I disagree. '12' (string) pass pass pass pass pass fail fail Absolute lunacy. Please let this be a typo. That part was indeed lunacy. '12.0' (string) pass pass pass pass pass fail fail '12.34' (string) pass pass fail pass pass fail fail As above. Fixed as well. I think you need to present this information better. One advantage of Ilia's proposal is that it is very clear. It does two things: strong type check, or the same casts that currently exist. I think you need to say what changes you are introducing, and why they are introduced. The same flaw existed with my proposal: I dont think anyone wants a 3rd set of rules. My proposals have a tendency to get this feedback. Probably because I write too much text and since I can also not produce a patch myself. Given that I have two large sections of text, one explaining the short comings of Ilia's approach and one explaining why I think that weak type checking solves this, I have taken this proposal as far as I can. If someone seems merit in it, please suggest improvements. I do not understand why its suddenly so urgent to get this feature in(*), that people already speak about frustration over the process after just a I think because this same issue has been going on for so long, and seem to be so very close now. This idea has been punted around in various forms and patches for years at this stage. So the solution is to sneak it in during the summer, right after a major releases for which some have even delayed their vacations? Then again, given the fact that within a few hours this proposal has gotten 5 +1, maybe I am being too paranoid .. well or Ilia is just doing a perfect job at orchestrating the masses. Either way we do not have processes for this .. so anything goes. few days. We dont need years and usually not months, but this is not the addition of some function. Its an extension to the language syntax, so I think its totally normal that we talk about this for at least a month. Well yes. But with near consensus, there is a danger of a 90% good-enough patch being derailed by new proposals, and I get the impression most people would be happier with the 90% patch. I have actually not felt much of an attempt to derail in the negative sense. But seeing that Ilia has labeled the "fairly detailed discussion" as "complaining for the sake of complaining" on his blog, I think that Ilia might be feeding this paranoia. shouldn't we rather talk about finding a better release process (maybe build on top of recent developments in the version control world) that enables us to more quickly get x.y releases out without preventing bigger features like unicode from ever maturing? I've heard you mention this before. Please roll it into an RFC so we can think about it (FWIW, the idea that newer version control systems will somehow change everything makes little sense, so I think a lot of detail is required here). Thanks. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On 04.07.2009, at 22:08, Lukas Kahwe Smith wrote: On 04.07.2009, at 21:10, Paul Biggar wrote: On Sat, Jul 4, 2009 at 7:12 PM, Lukas Kahwe Smith wrote: I can't see the difference between your proposal and the conclusion I reached yesterday? (which was that there is a near consensus around strict checks by default, with casts allowed with some syntax). Well to me it Sounded like you wanted to Rely on Standard Type juggling and what i am proposing is more strict than that. More over i am Not convinced that strict should Be the Default. I don't know what you mean by standard type-juggling. Your proposal really does not outline what you want very much, just what you're against. As for strictness, if your proposal suggests that strict typing is the default, I cannot see where. I did Not specify what doesnt Match in the RFC. I will fix that omission on monday. I assumed it was clear that i tried to Provide Complete examples for what will Pass. So Passung a String with anything but 1 or 0 would Not Pass à Bool Type check. Ok, I have updated the RFC now with a table that shows that I expect to pass and fail. Its fairly late, so I might have missed something. In general what I am proposing is more lax than is_*() for the most part. Especially when it comes to checking strings. I do not understand why its suddenly so urgent to get this feature in(*), that people already speak about frustration over the process after just a few days. We dont need years and usually not months, but this is not the addition of some function. Its an extension to the language syntax, so I think its totally normal that we talk about this for at least a month. Though we do not of course need a daily exchange of 100 emails about this in this period. Obviously things can still be refined after the commit, but we should stuff give everybody a bit of time to let this stuff sink in before we do the initial commit. Also remember that plenty of people that contribute a fair bit to PHP internals do not read internals actively every week. So again a month isn't such a bad idea to have between the initial proposal and a commit of the feature. regards, Lukas Kahwe Smith m...@pooteeweet.org (*) even if the patch Ilia proposed doesn't break binary compatibility anymore, do we really want to start adding such stuff in 5.3.2? shouldn't we rather talk about finding a better release process (maybe build on top of recent developments in the version control world) that enables us to more quickly get x.y releases out without preventing bigger features like unicode from ever maturing? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On 04.07.2009, at 21:10, Paul Biggar wrote: On Sat, Jul 4, 2009 at 7:12 PM, Lukas Kahwe Smith wrote: I can't see the difference between your proposal and the conclusion I reached yesterday? (which was that there is a near consensus around strict checks by default, with casts allowed with some syntax). Well to me it Sounded like you wanted to Rely on Standard Type juggling and what i am proposing is more strict than that. More over i am Not convinced that strict should Be the Default. I don't know what you mean by standard type-juggling. Your proposal really does not outline what you want very much, just what you're against. As for strictness, if your proposal suggests that strict typing is the default, I cannot see where. I did Not specify what doesnt Match in the RFC. I will fix that omission on monday. I assumed it was clear that i tried to Provide Complete examples for what will Pass. So Passung a String with anything but 1 or 0 would Not Pass à Bool Type check. The other Thing that i wanted to make clear is that After the weak Type check is that a cast should Happen afterwards. Finally i wanted to clarify my concerns about Structure typing to ensure that the Short Syntax is a weak check and only with additional Chars like the proposed ! Or something like that, can One get a Strict Type check. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On 04.07.2009, at 16:05, Paul Biggar wrote: Hi Lukas, On Sat, Jul 4, 2009 at 7:20 AM, Lukas Kahwe Smith wrote: Last evening I put together a quick proposal for a weak and strict checking approach, since I felt that things were being concluded a bit prematurely. More importantly I detailed the issues I see with a pure strict type checking only approach. I can't see the difference between your proposal and the conclusion I reached yesterday? (which was that there is a near consensus around strict checks by default, with casts allowed with some syntax). Well to me it Sounded like you wanted to Rely on Standard Type juggling and what i am proposing is more strict than that. More over i am Not convinced that strict should Be the Default. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] weak and strict type checking RFC
Hi, Last evening I put together a quick proposal for a weak and strict checking approach, since I felt that things were being concluded a bit prematurely. More importantly I detailed the issues I see with a pure strict type checking only approach. I am publishing it a bit prematurely imho, but its not without merit at this stage either and since I will be busy playing frisbee all weekend, I thought I get it out there for people to comment right now: http://wiki.php.net/rfc/typecheckingstrictandweak As Paul insisted that my initial proposal did not sufficiently high light the fact that there are other proposals, I moved my original proposal to the above location so that we can have a disambiguation page that lists all the various related proposals: http://wiki.php.net/rfc/typechecking Most of that is in there has been said/proposed on the list, so I am just pasting the key section on why I think strict checking is dangerous: Strict type checking does have the advantage that subtle bugs will be noticed more quickly and that function/method signatures will become yet more self documenting and therefore more expressive. Also doing these type checks based on the signature also means less code and better performance over having to hand code the validation Proponents of only providing strict type checking say that for the most part variables are defined with the proper type unless they come from an outside source, which usually requires validation anyways, which is a perfect opportunity to type cast. That is to define a variable that contains a boolean, developer will probably do “$is_foo = true” and not “$is_foo = 0”. While this may be true, it does means that developers using such strict type checking API's now require that users understand data types, which currently beginning developers do not necessarily need to. Furthermore quite often developers need to parse content out of strings and pass this to other methods. With strict type checking one is now forced to explicitly type cast. While its certainly doable, its also additional work that needs to be done while writing the code (“$foo_int = (int)substr($bar, 3, 10)”). Then again some might argue that this makes the code clearer. It also means that users of such strict typed API's will tend to simply cast and due to laziness (PHP is used for rapid development after all) might forgo validating first if the content is really what they expected. Without type checking the burden would be with the developer providing the API. Since its usually expected that an API is fairly often, it seems illogic to move this burden to the API users. More over due to this, a new kind of bug will be introduced due to over use of cast instead of hand coded parameter validation as is currently necessary. This could lead to even higher bug rates. As for outside sources needing validation. This is not always the case as most people do trust that the data returned from a database is in the expected format, even though for most RDBMS it will always be returned as string. Same applies to configuration files, which if defined in something else than PHP code will most likely only return strings, but who's values will usually not be validated. regards Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 03.07.2009, at 15:04, Paul Biggar wrote: Since this can be built as an extra step on top of your patch, this can be added later (although it would obviously be great if you preferred to add it now...). I recommend you proceed with the next step of getting your patch accepted (I presume an RFC or something). Going by Ilia's comments about RFC's on IRC, I guess someone else should take on writing an RFC, summarizing the discussion, linking important ml posts and moving forward with a vote, keeping in account the various relevant options/variations suggested. This RFC here can serve as a starting point: http://wiki.php.net/rfc/typehint Remember anyone can request a wiki account and do this. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 03.07.2009, at 15:04, Paul Biggar wrote:
Hi Ilia,
On Thu, Jul 2, 2009 at 3:35 AM, Paul Biggar
wrote:
Thanks to Ilia for getting to ball rolling on scalar type hinting.
I believe I have a solution that caters to each crowd, without being
too complicated.
My impression is that there only minor support for the "flexible"
approach, and that even then, everyone prefers strict checking by
default. So the ideal seems to be your patch, with the addition of
function x ((int) $casted_parameter) { ... }
hmm not sure that the consensus of a "weak" check would be an
automatic cast. Actually that wouldnt be much of a check in that case.
I think the other side is more asking for what Ilia already begun with
"numeric" in the sense of a weak checker. After the check it could go
ahead and cast too for all I care, but it shouldnt be the equivalent
of a cast. But maybe you are not implying that and I am just getting
confused by the syntax.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 02.07.2009, at 15:02, Ilia Alshanetsky wrote: Personally, I am uncertain about +int or -int in general, IMO that compromise will eventually be identical to numeric an cause endless confusion for the users between (+/-)int and int. The reason I used a completely different name is to prevent confusion. I do not see the risk for confusion as being high. Like I said, I havent made up my mind on this proposal, however for now Paul mainly asked for feedback in the general concept, not necessarily on the syntax. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Boxing and Unboxing
Hi, I recommend that you sign up on the wiki and publish your proposal on wiki.php.net/rfc regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flexible type hinting
On 02.07.2009, at 10:45, Paul Biggar wrote: to work in a future with a library/framework that is strict about its input or some far fetched idea that it will change the very nature of PHP. I don't think we are worried about it changing PHP, or about libraries using strict type hints. We are worried that libraries will use no hints, because the ones on offer are not useful to them. I think he is replying to me here. I am worried that with Ilia's proposal, people will strictly type everything, even where weakly typed would suffice. The reason being that developers are lazy. With these type "hints" (they are not actually hints, but "checks" as you already made clear), they can very easily move the burden of type juggeling explicitly to the user of their code. At least in my world, I use a lot of 3rd party libraries, which will then likely become essentially strictly typed. While strictly typing can prevent bugs and all sorts of good stuff, we should be more hesitant when it comes to giving people tools that make it easy (encourage) to turn a core principle of PHP upside down. I know that "numeric" was a concession to people with my concern from the last discussion. But it doesnt cover all the bases of types. In that vain Paul's proposal does indeed provide a syntax that at least enables both approaches. More importantly it proposes a syntax that requires the same number of characters for both approaches. You might laugh at this comment, but I believe that the overuse of "private" that I am seeing has a lot to do with the fact that its shorter than "protected". I have not really made up my mind about Paul's proposal, but I just wanted to make the above points. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] create_function/zend_eval_string aren't binary-safe
On 03.06.2009, at 20:45, Matt Wilmas wrote:
Hi all,
I first noticed this with preg_replace()'s /e modifier (SO many
other issues with that...), but it also happens with
create_function() and a few other places where zend_eval_string() is
used. Other code evaluation in PHP is binary-safe, so it seems like
these areas should be as well? In case an example is needed:
$func = create_function('', "return strlen('Test\0string');");
echo $func();
Patches:
http://realplain.com/php/binary_eval_string.diff
http://realplain.com/php/binary_eval_string_5_3.diff
Can they be applied? (Also a small optimization by eliminating
strlen() usage.) May want to verify the ext/interbase change.
I noticed there are several zend_eval_string() references in PECL
sources [1], which would be a problem after adding a string length
parameter... How is that handled? Should the updated function be
eval_stringL instead and add macros for compatibility?
[1] http://lxr.php.net/ident?i=zend_eval_string
should this be applied now as it hasnt been applied yet, afaik?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.0 Released!
Hello! The PHP Development Team would like to announce the immediate release of PHP 5.3.0. This release is a major improvement in the 5.X series, which includes a large number of new features and bug fixes. Release Announcement: http://www.php.net/release/5_3_0.php Downloads:http://php.net/downloads.php#v5.3.0 Changelog:http://www.php.net/ChangeLog-5.php#5.3.0 regards, Johannes and Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On 26.06.2009, at 17:26, Lukas Kahwe Smith wrote: After this period bug fixes can be applied again. However feature additions should wait until after 5.3.1, which we expect to be released within a month or two. As always if you are unsure, ask Johannes. And also as always if there is a solid reason, common sense rules, but please do ask first. Ok, so we are in the process of announcing 5.3.0. So you can now go ahead and commit bug fixes without prior review into 5_3. Please hold off from feature additions for now or bring them up on internals if you feel they are urgent. I will start notifying developer about bug fixes that should be merged now. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On 26.06.2009, at 20:26, Pierre Joye wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] post 5.3.0 development
Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. After this period bug fixes can be applied again. However feature additions should wait until after 5.3.1, which we expect to be released within a month or two. As always if you are unsure, ask Johannes. And also as always if there is a solid reason, common sense rules, but please do ask first. regards, Johannes and Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
On 23.06.2009, at 08:15, jvlad wrote: 1. you're wrong, PHP does not depend on system-wide installed pear, it will simply use it if present 2. nothing is missing. see http://pear.php.net/PHP_Archive If installed, phar.phar will function (partially) without the phar extension being present. In other words, not a problem, not a bug. Greg, Can the messages be enhanced e.g. explaining what will happen in these cases? For example "pear: not found. Using XXX instead" would help users for #1. As far as I understand "pear: not found" is a shell message thrown into output (stderr?) when make tried to run non-existing system's pear. if someone has a safe looking patch to improve this, we can consider including it in 5.3.0 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3.0 stable delayed until next Tuesday
Aloha, As most of you following this list have noticed, alot of last minute stuff has been brought up. So it goes. Johannes and Pierre have put in extra time in trying to still make it for a release tomorrow, however as the stream of patches and open issues has continued even today, we have decided to play it safe and move the release date to next Tuesday. We will package tomorrow evening and push out the release to mirrors next Monday. Again we urge everybody to only commit into 5_3 after Johannes has reviewed the patch. Therefore all patches should be send to internals. That being said this is the list of things we are still looking into at this point: - mysqlnd crash - jvlad's sparc "tmp is not being properly initialized by INIT_ZVAL" issue - possibly a crash fix in Date (Derick any news on that?) Everything else will have to wait for 5.3.1, this includes: - Stas's proposed change to make JSON optionally shared on windows - Greg's openssl phar fix - Christians spl_autoload_unregister closure fix - David's Datetime SOAP addition - Improvements to re2c parsing with certain file sizes - etc. Again we are trying to wrap things up here. So we are really focusing on the worst of segfaults/crashes etc. regards, Johannes and Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS
On 22.06.2009, at 17:51, Takeshi Abe wrote: tabeMon Jun 22 15:51:50 2009 UTC Modified files: (Branch: PHP_5_3) /php-src NEWS Log: moved to PHP_5_2 http://cvs.php.net/viewvc.cgi/php-src/NEWS?r1=1.2027.2.547.2.965.2.641&r2=1.2027.2.547.2.965.2.642&diff_format=u Index: php-src/NEWS diff -u php-src/NEWS:1.2027.2.547.2.965.2.641 php-src/NEWS:1.2027.2.547.2.965.2.642 --- php-src/NEWS:1.2027.2.547.2.965.2.641 Mon Jun 22 11:44:49 2009 +++ php-src/NEWSMon Jun 22 15:51:49 2009 @@ -5,8 +5,6 @@ (crrodriguez at opensuse dot org) - Fixed bug #48620 (X-PHP-Originating-Script assumes no trailing CRLF in existing headers). (Ilia) -- Fixed bug #48555 (ImageFTBBox() differs from previous versions for texts - with new lines) (Takeshi Abe) - Fixed bug #48215 (Calling a method with the same name as the parent class calls the constructor). (Scott) Actually .. most likely this issue will be first fixed in 5.3.0 stable, before we will see a 5.2.11 stable. So where should this be listed in? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3.0 stable release
Hi, It looks like nothing critical has popped up since RC4. So it looks like we will be sending the final stable release to the mirrors next Wednesday and announce the release on Thursday barring any critical issues emerging in the next days. In the mean time test test test. If issues are found/fixed please send the patches to internals for review. Based on the importance and risk of the patch will then be applied, however the next 2 days should really be focused on testing to make sure we do not have critical issues, minor issues can always be fixed in 5.3.1 and we better release with known minor issues than big unknown issues caused by a last minute fix. Another focus area should be the migration guide and other documentation updates: http://docs.php.net/migration53 regards, Johannes and Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC4
On 21.06.2009, at 10:29, Lukas Kahwe Smith wrote: On 21.06.2009, at 10:24, Lester Caine wrote: Lukas Kahwe Smith wrote: On 21.06.2009, at 09:51, Lester Caine wrote: Johannes Schlüter wrote: On Sat, 2009-06-20 at 07:49 +0100, Lester Caine wrote: While I know that ... - All ereg functions are deprecated and emit E_DEPRECATED errors. Use PCRE (preg_*()) instead. ... is accurate, I think a little more detail would help here, since many of us probably did not know that 'split' was an ereg function - for instance? hm, the las version on the wiki listed them ... In general: I'd like if people could come up with more details and add them to the docs. (See Rasmus's mail) So that this file is as short as i makes sense so people have a chance to be aware of as much contents as possible - and isn't scared away. I was probably looking more for pointers to some extra information. Part of the problem here is that the warnings are being thrown in code that *I* did not write, so then one either has to search for updated versions of a library or work out how to fix them yourself - where I'd 'borrowed' the code originally. Simply hiding E_DEPRECATED is likely to lead to even bigger blowups later? :( Actually E_DEPRECATED is only something you should enable temporarily. Then you can alert either your own team, or the project who's code you are using and move on. It simply tells you that the code will break with the next major version. This is not an end of world fatal error. On a production site - probably - but I see no reason to disable it on the development sites. It's all to easy to grab a bit of code and drop it in, forgetting that it's now on the 'deprecated' list. I avoid libraries that throw errors and will only work with 'display_errors=off'. If I need to use them then I will fix any errors even if 'non-fatal' before using the code in production! So before PHP5.3 is acceptable for production, any warning needs to be addressed - at least in my book. There is a reason why E_DEPRECATED isn't part of E_ALL. Anyways, its your call, but its not what we suggest. But overall there is always room for doc improvements (feel free to help out), but in the end you need to know the code or familiarize yourself with the code if you want to "fix" it, though per se .. there is nothing broken with the code in the current version of PHP. Ok, guess I am wrong here. Its part of E_ALL as I suggested it when I proposed E_DEPRECATED initially. Since it seems I was the only one that considered not including it in E_ALL. That being said, for development we currently suggest: error_reporting = E_ALL | E_STRICT And for production: error_reporting = E_ALL & ~E_DEPRECATED So I guess we are pushing people towards fixing deprecation issues a bit more forcefully than I thought. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC4
On 21.06.2009, at 10:24, Lester Caine wrote: Lukas Kahwe Smith wrote: On 21.06.2009, at 09:51, Lester Caine wrote: Johannes Schlüter wrote: On Sat, 2009-06-20 at 07:49 +0100, Lester Caine wrote: While I know that ... - All ereg functions are deprecated and emit E_DEPRECATED errors. Use PCRE (preg_*()) instead. ... is accurate, I think a little more detail would help here, since many of us probably did not know that 'split' was an ereg function - for instance? hm, the las version on the wiki listed them ... In general: I'd like if people could come up with more details and add them to the docs. (See Rasmus's mail) So that this file is as short as i makes sense so people have a chance to be aware of as much contents as possible - and isn't scared away. I was probably looking more for pointers to some extra information. Part of the problem here is that the warnings are being thrown in code that *I* did not write, so then one either has to search for updated versions of a library or work out how to fix them yourself - where I'd 'borrowed' the code originally. Simply hiding E_DEPRECATED is likely to lead to even bigger blowups later? :( Actually E_DEPRECATED is only something you should enable temporarily. Then you can alert either your own team, or the project who's code you are using and move on. It simply tells you that the code will break with the next major version. This is not an end of world fatal error. On a production site - probably - but I see no reason to disable it on the development sites. It's all to easy to grab a bit of code and drop it in, forgetting that it's now on the 'deprecated' list. I avoid libraries that throw errors and will only work with 'display_errors=off'. If I need to use them then I will fix any errors even if 'non-fatal' before using the code in production! So before PHP5.3 is acceptable for production, any warning needs to be addressed - at least in my book. There is a reason why E_DEPRECATED isn't part of E_ALL. Anyways, its your call, but its not what we suggest. But overall there is always room for doc improvements (feel free to help out), but in the end you need to know the code or familiarize yourself with the code if you want to "fix" it, though per se .. there is nothing broken with the code in the current version of PHP. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC4
On 21.06.2009, at 09:51, Lester Caine wrote: Johannes Schlüter wrote: On Sat, 2009-06-20 at 07:49 +0100, Lester Caine wrote: While I know that ... - All ereg functions are deprecated and emit E_DEPRECATED errors. Use PCRE (preg_*()) instead. ... is accurate, I think a little more detail would help here, since many of us probably did not know that 'split' was an ereg function - for instance? hm, the las version on the wiki listed them ... In general: I'd like if people could come up with more details and add them to the docs. (See Rasmus's mail) So that this file is as short as i makes sense so people have a chance to be aware of as much contents as possible - and isn't scared away. I was probably looking more for pointers to some extra information. Part of the problem here is that the warnings are being thrown in code that *I* did not write, so then one either has to search for updated versions of a library or work out how to fix them yourself - where I'd 'borrowed' the code originally. Simply hiding E_DEPRECATED is likely to lead to even bigger blowups later? :( Actually E_DEPRECATED is only something you should enable temporarily. Then you can alert either your own team, or the project who's code you are using and move on. It simply tells you that the code will break with the next major version. This is not an end of world fatal error. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC4
On 19.06.2009, at 10:50, Lukas Kahwe Smith wrote: Hello! we have packaged PHP 5.3.0RC4, which you can find here: http://downloads.php.net/johannes/ Windows binaries are available here: http://windows.php.net/qa/ This this release candidate focused on bug fixes and stability improvements and we hope to only require minimal changes ahead of the next release. Many, but not all, of the new features are already integrated in the official documentation on php.net. We aim to release PHP 5.3.0 next week. In case of critical issues we will continue producing weekly RCs. For most users there will not be a noticeable change meaning that now is the time to really do the final testing of PHP 5.3.0 before it gets released with any unnecessary incompatibilities with your project. We are really close, however there is obviously a steady stream of new tickets being opened [1]. Some of these include bugs in new functionality and some include BC breaks. At this point Johannes and I are not aware of any show stopper bugs yet though. We very much appreciate every effort to review those bug reports and as much testing as possible with real world applications. Please let us know ASAP if you do think that there is a show stopper bug. Also please do not commit to 5_3 without the explicit permission of Johannes. Please post any 5_3 patches to internals for peer review. We have had a few last minute commits break things and so we ask you to accept this additional step before commits for the hopefully short time period until 5.3.0 stable. Best Regards, Lukas and Johannes PHP 5.3 Release Managers [1] http://bugs.php.net/search.php?status=Open&phpver=5.3&cmd=display -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.0RC4
Hello! we have packaged PHP 5.3.0RC4, which you can find here: http://downloads.php.net/johannes/ Windows binaries are available here: http://windows.php.net/qa/ This this release candidate focused on bug fixes and stability improvements and we hope to only require minimal changes ahead of the next release. Many, but not all, of the new features are already integrated in the official documentation on php.net. We aim to release PHP 5.3.0 next week. In case of critical issues we will continue producing weekly RCs. For most users there will not be a noticeable change meaning that now is the time to really do the final testing of PHP 5.3.0 before it gets released with any unnecessary incompatibilities with your project. Some additional links to get started: http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=markup&pathrev=PHP_5_3 http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?revision=PHP_5_3 Best Regards, Lukas and Johannes PHP 5.3 Release Managers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NaN still broken on Windows builds?
On 24.05.2009, at 11:53, Carsten Wiedmann wrote: Hello, var_dump(NAN); // float(0), should be float(NAN) $realNaN = sqrt(-1); var_dump($realNaN); // float(NAN) var_dump($realNaN == $realNaN); // true, should be false, NaN should never match NaN That's interesting. With my own 5.2.9 build (vc6), I have "false" in the last test (comparing the variable): | # php -n -r "var_dump(NAN);$n=sqrt(-1);var_dump($n);var_dump($n== $n);" | float(0) | float(NAN) | bool(false) With the official 5.2.9 or 5.2.10-dev builds it's "true" on the same machine (xp sp3). BTW: is_nan($realNaN) is working with the official build. is this fixed? and if not .. is there a bug ticket open? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] set_magic_quotes_runtime is still E_DEPRECATED
Hi, This seems like a trivial change from the implementation side, so I am not worried about changing this for the "better" even after RC4 (given proper documentation. So here are the choices I see: 1) stay as is .. aka defaults to on while not emiting an E_DEPRECATED, do emit E_DEPRECATED when using the setter 2) as per Zeev, leave the default as is and change things when using the setter as follows: "emit E_DEPRECATED in case of true and nothing in case of false; For 6 - emit an error for true and nothing for false." (so he is also suggesting to revert the removal of the setter in PHP6) 3) stay as is .. aka defaults to on while not emiting an E_DEPRECATED, but do not emit E_DEPRECATED when using the setter to disable 4) change the default to off, for the rest stay as is A few notes: First up we are late in the RC stage. Also E_DEPRECATED is a "checker tool" you enable temporarily during development. I expect most people to use a php.ini supplied by whatever distro they are using or simply update their current php.ini, in which case they are most likely setting a value for this setting explicitly, which should cause and E_DEPRECATED if enabling this feature. I am also not sure which if the other settings that we are removing in PHP6 are also on by default, but obviously if we change something here, we are opening pandora's box to those as well: - define_syslog_variables - register_globals - register_long_arrays - safe_mode Please keep things as concise as possible when you reply. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: bug #48247 again
On 16.06.2009, at 20:53, Stanislav Malyshev wrote: Hi! so if this issue is also in 5.2 .. i feel even less inclined to delay a stable 5.3 release because of this issue. have we made it worse in our attempts to fix it? the fact that this bug isnt fixed yet could mean No, it was crash before, now it doesn't crash for me but produces 400K of errors. One can argue it's better now, though pretty marginally as in both cases system can not be considered stable. Of course, there's an easy workaround of setting the timezone. It seems only you and Derick have expressed an opinion. If no one else speaks up I would tend to leave as is and fix it in 5.3.1 (and HEAD asap) and simply make sure that we put it in bold letters in the UPGRADING guide that you really should set the timezone. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] set_magic_quotes_runtime is still E_DEPRECATED
On 16.06.2009, at 20:59, Greg Beaver wrote: Lukas Kahwe Smith wrote: 1) its not about "punishing", its about alerting people that they are relying on stuff that will go away 2) E_DEPRECATE is for development only and only as a check you enable now and then 3) its off in both of the php.ini's we will ship with 5.3 OK, then the UPGRADING guide needs a slight revision. It says: - The following ini directives will now emit an E_DEPRECATED warning upon startup if they are activated: - define_syslog_variables - register_globals - register_long_arrays - safe_mode - magic_quotes_gpc AFAIK Kalle worked on adding E_DEP's for these settings at start up time. Sounds like there is a bug there if they are not showing up for you. Do you maybe have have start up error's disabled? This is incorrect. No E_DEPRECATED is emitted, unless one tries to disable it. Lets stay a bit of the drama here. If you disable it in the php.ini you will not see this warning. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] the role of RM's (as I see it)
On 16.06.2009, at 20:53, Stanislav Malyshev wrote: We don't need to delay it if we decide to commit my (incomplete) fix now. Anyway, it's your decision, one of the three: 1. leave it as is, 2. commit incomplete fix now, 3. wait for complete fix. I agree 3 is the worst, I'd go with 2 but if you decide to go with 1 that's OK. Just to clarify how I see the job of an RM. Its not chief decision maker. Its decision facilitator. Only when with reasonable amount of time and input from the community no agreement/compromise can be found, I can see the RM act as a tie breaker. As such I prefer to get feedback from as many people as possible in a clear and concise manner that makes it easy for us RM's to understand the view points of the community, so that we can then simply sum of the conclusion of the discussion and ask someone to make the necessary changes. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] set_magic_quotes_runtime is still E_DEPRECATED
On 16.06.2009, at 19:39, Greg Beaver wrote: Daniel Convissor wrote: Folks: I propose the following behavior: "Throw a deprecated warning unless magic quotes are currently enabled and the parameter is to disable them". The function is going away. A deprecated warning is necessary to alert people of this fact, no matter how the function is used. I'm sorry, but there is a bug here. On my system, magic_quotes_gpc is enabled by default, and no E_DEPRECATED warning is thrown. Check it out. Compile a vanilla PHP 5.3, and run php -n -i |grep magic It's probably an oversight, but if it is intentional, we can't punish people for disabling something that is enabled by default. 1) its not about "punishing", its about alerting people that they are relying on stuff that will go away 2) E_DEPRECATE is for development only and only as a check you enable now and then 3) its off in both of the php.ini's we will ship with 5.3 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: bug #48247 again
On 16.06.2009, at 18:56, Stanislav Malyshev wrote: Hi! So lets delay fixing this issue until 5.3.1? Of course it can be fixed in HEAD right now :) Delaying the fix would mean we release 5.3.0 that in mostly default config has an infinite loop bug. Maybe we can at least have temp fix and then when we have a proper one then remove it (or leave it in, it wouldn't hurt anybody)? For 5.2 it's even worse since I understand 5.2 is not intended to be developed past 5.2.10, except for security fixes. so if this issue is also in 5.2 .. i feel even less inclined to delay a stable 5.3 release because of this issue. have we made it worse in our attempts to fix it? the fact that this bug isnt fixed yet could mean several things like: 1) the issue affects few users 2) the issue is so complex that we continuously try to fix it and fail both issues do not sound like good reason to delay 5.3 from where i stand. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: bug #48247 again
On 16.06.2009, at 10:07, Derick Rethans wrote: On Thu, 11 Jun 2009, Stanislav Malyshev wrote: Bug #48247 appears to be not entirely fixed still, it still produces a torrent of warnings in certain configs (namely, take php.ini-production and edit it to enable error_log, don't touch anything else - I get 400K worth of warnings). Attached patch should fix it. Please tell if there's some objection to it, otherwise I'll commit it tomorrow. The attached patch does fix one of the symtomps of the issue, but not the real problem. The real problem here is that from an error handler, another error is thrown. Instead of fixing this as a hack in any extension that has influence on formatting of error messages or error handling (through overriding the callback), a fix should be done in the error handling mechanism in order to prevent an error message generating another error message. So lets delay fixing this issue until 5.3.1? Of course it can be fixed in HEAD right now :) regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #48247 again
On 11.06.2009, at 20:00, Stanislav Malyshev wrote: Hi! Bug #48247 appears to be not entirely fixed still, it still produces a torrent of warnings in certain configs (namely, take php.ini- production and edit it to enable error_log, don't touch anything else - I get 400K worth of warnings). Attached patch should fix it. Please tell if there's some objection to it, otherwise I'll commit it tomorrow. So whats going on here? I noticed that the bug report hasn't been reopened .. but I think there was also not commit yet .. ? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Last steps towards 5.3.0
On 10.06.2009, at 16:43, Johannes Schlüter wrote: June 10th (today): We package RC3, until then only critical build fixes and similar which have to go in the RC, after review (highlight me on IRC, mail etc.) June 11th: RC3 will be released June 11th-17th A small window for critical fixes and again please check beforehand as we don't want to introduce any new bugs that late in the game. June 17th In case there were commits after RC3 we will package a RC 4 on Wednesday next week Ok, we are here now. So we are in a commit freeze as of this morning until sometime Wednesday. When we have tagged RC4, please only commit to 5_3 with the explicit blessing of Johannes until we release 5_3 stable or announce an extension of the RC phase. So far I want to get clarification on how set_magic_quotes_runtime(0) behaves in PHP6. I also talked to Pierre about the late changes in windows (which Johannes and I were aware of since weeks). Its clear that this change will not hold up any releases. Pierre will revert if necessary. June 18th If needed publish RC4 June 18th - June 24th The plan is to repackage RC4 as 5.3.0 final in the beginning of the week of the 21st without any further changes so we can test the packages. In case something critical, unexpected, pops up please notify us asap. June 25th 2009 Release PHP 5.3.0 final. We are still on track for this one. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] set_magic_quotes_runtime is still E_DEPRECATED
On 16.06.2009, at 05:08, Greg Beaver wrote: Hi, in PHP_5_3 if you're using set_magic_quotes_runtime(0), it raises an E_DEPRECATED. I thought all that argument was resolved to only throw E_DEPRECATED for set_magic_quotes_runtime(1)? This is a major pain if magic_quotes are enabled and you need to turn them off to do unserialize or serialize to a file. The purpose of E_DEPRECATED is to alert of changes in up coming major PHP versions. So if the function is removed entirely from PHP6, then the way things are is correct. If the function still exists, but simply doesn't do anything (or even raises an error) when "set_magic_quotes_runtime(1)" is called, but silently continues when "set_magic_quotes_runtime(0)" is called, then it should be changed as per Greg's request. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Last steps towards 5.3.0
On 10.06.2009, at 16:43, Johannes Schlüter wrote: Hi, it was a long run so far and it's time to really take the last steps to get the beast out. For this Lukas and I decided on the following plan: June 10th (today): We package RC3, until then only critical build fixes and similar which have to go in the RC, after review (highlight me on IRC, mail etc.) ok this step is completed June 11th: RC3 will be released June 11th-17th A small window for critical fixes and again please check beforehand as we don't want to introduce any new bugs that late in the game. Ok, we are out of commit freeze. @Ilia: go ahead and merge your fix for #48512 @Tony: you can now apply that curl arginfo patch and the fix for the curl crash @Pierre: you can now also apply the patches you were looking to commit @Hannes: I guess we will wait until Johannes has determined if the patch is really necessary @Andrey: I guess you will/have talked to Johannes about your patches regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Last steps towards 5.3.0
On 10.06.2009, at 17:33, Greg Beaver wrote: Guilherme Blanco wrote: Just 2 questions 1- Will it include new autoloader definition that standards group was talking about? no .. there was no proposal, therefore no discussion, therefore its not going to be included, since we are long past adding new features. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] commit freeze for 5.3 branch ahead of thursdays RC3 release
Ahoi, Just a heads up, as announced last week, we are in a commit freeze effective since this morning on the 5.3 branch. If all goes according to plan we will release RC3 this Thursday hoping for this release to become the golden stable release. We will announce the end of the commit freeze sometime during Wednesday. As things look we will stick with re2c as is (including Dmitry's hack to fallback to 5.2 behavior if the new mmap solution doesnt work). Derick is close to having a full fix, but Derick is short on time to really get out all the kinks this can also just get into 5.3.1. Again a commit freeze means no commits to any part unless its clearly a build fix or just touches README's. When in doubt ask Johannes (who should be available again some time tonight). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Notes from the PDM in Chicago
On 03.06.2009, at 22:52, Andrei Zmievski wrote: I don't want people here to assume that these notes are "decisions" necessarily. They reflect the consensus of the group that was at the meeting and we should still take up the unresolved or arguable issues on this list. But hopefully we have a more structured and outlined list of things that we can follow for PHP 5.4/6. There are a couple of items that were unclear from the original notes — looking at you, Liz Smith :) - so, those of you who remember the discussion, please fill them in. To me its absolutely critical that we do not give the impression that the next bigger update after 5.3 will be 5.4. The next big thing is 6.0. If we do a 5.4 then it will come after 6.0, just like 4.4 to ease migration. But it makes no sense to release 5.4 with forward compatibility stuff until we know we really nailed 6.0. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
