Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Thu, 29 Nov 2007, Marcus Boerger wrote: I do not care for IBM problems. Not at all. If people want to commit they can do it in their free time. If IBM now thinks they have to make PHP suitable for their own stuff then they are obviously willing to spend quite some interest because they have a much bigger business interest. That said I am confident they can find ways to deal with it inside IBM itself. But they do not like to do it as that would be much more expensive for them. Also the trouble is that then they would need to be real open source. To add to this, I think that if IBM (and others) are so keen on having PHP support their nice databases, they should also realize that it is them that should be nice to *us* and not the other way around. We (as in PHP project) shouldn't have to change the ways how we're dealing with contributions at all. It should be the big companies that actually have a financial interested in PHP supporting their software that open up more and appease us. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Thu, 29 Nov 2007, Stanislav Malyshev wrote: Having a clear and transparent contribution process is much more important to my eyes than good support for some company's products. No, it is not more important. 99.9% of PHP users don't care what process we have, they care about how well PHP works for them. This is irrelevant, because the users where not in question here. And they only don't care because they have no idea how this stuff is going to affect a big part of the contributers to PHP. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Fri, 30 Nov 2007, Dan Scott wrote: In that case, you should: 1) Have a legal entity that you can assign copyright to (PHP Group and PHP Documentation Group are not legal entities and therefore cannot hold copyright) and Actually, I think the issue is more that: However, a ~couple months ago IBM gave permission to remove this copyright (because the authors are listed as general contributors, thus representing IBM) although we've not yet implemented this removal. We did [temporary] remove it about six months ago but... There is no requirement in most countries* to show that something is copyrighted, as it's a basic right. It's protected by default, so the whole © 2005 IBM Corporation is unnecessary. None of the other contributers ever required something like this. * Atleast in the Netherlands, and what I gather from wikipedia also in the US through the Berne convention (http://en.wikipedia.org/wiki/Berne_Convention_for_the_Protection_of_Literary_and_Artistic_Works) regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
On Mon, 3 Dec 2007, Andi Gutmans wrote: Sorry about that. Does the attached PDFed screenshot work for you? No, as you can't attach files here Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
On Mon, 3 Dec 2007, Brian Shire wrote: On Dec 3, 2007, at 2:17 PM, Stanislav Malyshev wrote: I am a developer on a CMS also which uses the auto-include functionality to include many classes over many files. Each request can include up to 30 different files. The speed increase is around the 15% mark when combining the files. This is with APC installed too. Can you provide some benchmark setups that this could be researched - i.e. describe what was benchmarked and how to reproduce it? I've seen this come up before internally at Facebook. Many people do a microtime() test within there code and consider this a definitive benchmark of how fast there script runs. Unfortunately this excludes a lot of work that's done prior to execution. FWIW: Xdebug's xdebug_time_index() function does not have this issue, as it starts in RINIT. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Dropping Namespace
Hello,
following some discussions on the list (re. multiple namespaces in file)
as well as a short discussion on IRC regarding not being able to do
use yeti::xml::DomDocument as DomDocument; - I do not see any point in having
namespaces at all. And my excuses for the somewhat longish mail...
Some arguments:
1. As it is impossible to do use XXX as NativeClass we get to the
point where we'd have to namespace new internal native classes
otherwise we might introduce BC breaks. AFAIK, we've always said that
PHP reserves the globals space for it's own use (see also:
http://www.php.net/manual/en/userlandnaming.rules.php). In case we do
add new classes (an example could be DateTimeSpan), they should of
course follow the same format as already existing classes in the
extension (DateTime, DateTimeZone). However introducing the new class
DateTimeSpan might break people's code that do things like:
?php
use myNamespace::DateTimeZone as DateTimeZone;
?
feature versions of people would then show:
Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument
because the name is already in use.
It would be silly to require to have to do this:
- Create a class PHP::Date::TimeSpan
- In your scripts:
use PHP::Date::TimeSpan
But with the current implementation, this seems to be the only non-BC
breaking solution. If we chose *not* to require this silly namespacing
of internal classes, users instead have to do this:
?php
use myNamespace::DateTimeZone as myDateTimeZone;
?
Basically prefixing the classnames... This you can already do just
fine without namespaces.
2. You have to import every class yourself. You can currently not do:
use myNamespace::* as *; // or similar syntax
I understand why this is not implemented (runtime vs. compile time),
but it is a bit of a pain in the ass if you use lots of classes from
your own library f.e.
3. We keep bickering over using { } or not, multiple namespaces in a
file or not... etc. I understand that people want more flexibility,
but also we need a *simple* to explain implementation. With the
current implementation I see the following problems here:
- You can't stick multiple namespaces in one file
- Unlike other constructs in PHP that mark executable blocks,
namespaces don't use { }.
- The namespace keyword at the start of a file is somewhat magic,
because it can only appear as first element in your script.
4. What is wrong with simple prefixes in the first place? Both PEAR_*,
Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
'namespaces'. We could optionally create a registry on php.net for
this to avoid conflicts.
With all the above considerations, especially my first point, I still have not
heard any good reason why namespaces in the current implementation are actually
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not, and for myself
(and most likely my work projects) I would have to decide not to go with
namespaces, but instead stick with the 3 letter prefixing. Something that I
have totally no problem with, as it is nice and easy.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Tue, 4 Dec 2007, Larry Garfield wrote:
1) use MyDate as DateTime. I believe Greg pointed out the solution here.
When PHP 5.5 is released and adds its own Whatever class, you just do the
following:
namespace me;
use Whatever as LegacyWhatever;
class Whatever{}
It's a one-line change to keep your code working. I think that's acceptable,
It's not acceptable, as you're breaking BC.
For whatever the opinion of someone who writes PHP all day and not C
is worth, there it is.
What makes you think I am different?
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Tue, 27 Nov 2007, Wez Furlong wrote: All will be revealed soon. Just wondering what sort of timeframe you mean with soon... any idea? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
On Tue, 4 Dec 2007, Andi Gutmans wrote: To clarify I meant there's a tri-state (not compiled in, compiled in but collection turned off, compiled in but collection turned on). My recommendation was to always compile it in but to keep collection turned off by default. That's totally fine with me. With David's patch you could turn it on with both an ini setting (PHP_INI_ALL) or with a function. Can the improved one do so as well? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] Garbage collector patch
On Wed, 5 Dec 2007, Matthias Pigulla wrote: To summarize the patch lead to approx. 5% slowdown and 3% memory overhead for typical applications (as always, you mileage may vary depending on your system's architecture and OS although my guesstimate is that you will see even worse results in a 64bit environment). Does that slowdown result from housekeeping tasks alone that are a prerequisite for GCing or does it include running the new algorithm? Is it possible to always perform (unconditionally compile in) the necessary housekeeping tasks but stick with the current GC, so that cycle-detection only happens when the user calls a gc_go_find_cycles() function? Would that significantly improve the above numbers? Yes, that would be possible, but it wouldn't speed anything up in case you don't have any cycles. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: AW: [PHP-DEV] Garbage collector patch
On Wed, 5 Dec 2007, Matthias Pigulla wrote: Is it possible to always perform (unconditionally compile in) the necessary housekeeping tasks but stick with the current GC, so that cycle-detection only happens when the user calls a gc_go_find_cycles() function? Would that significantly improve the above numbers? Yes, that would be possible, but it wouldn't speed anything up in case you don't have any cycles. Not sure I got you right. That is, the speed penalty comes from housekeeping? Does the new GC try to find cycles automatically whenever a refcount goes down to zero? Not immediately... the algorithm should only run when either the root buffer is full, or the function is run manually. If building and maintaining data structures for the algorithm costs only a little memory but speed impact is neglegible unless the algorithm actually runs, then you could stick with the non-cycle-detecting legacy GC (= speed) unless you know you have cycles and/or want to trade a little processing time (a call to gc_go_find_cycles()) for the memory it will/might free. Yes, exactly. But it's just as easy to turn automatic cleaning as well - in that case the find cycle algorithm will kick in at some specific amount of freed vars. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
/zend_vm_execute.h:87
execute_data = {opline = 0x1e3a198, function_state = {function =
0x1e17c70}, fbc = 0x0, called_scope = 0x0, op_array = 0x1e17c70, object = 0x0,
Ts = 0x7fff9c73f660, CVs = 0x7fff9c73f640, original_in_execution = 1 '\001',
use_heap = 0 '\0', symbol_table = 0x1e9bb90, prev_execute_data =
0x7fff9c740df0,
old_error_reporting = 0x0}
#4 0x008c4dec in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff9c740df0) at
/home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:221
original_return_value = (zval **) 0x7fff9c741060
opline = (zend_op *) 0x1e1b428
current_scope = (zend_class_entry *) 0x1dcd560
current_called_scope = (zend_class_entry *) 0x1dcd560
current_this = (zval *) 0x1d7f670
should_change_scope = 1 '\001'
ex_object = (zval *) 0x0
#5 0x008c5b0d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fff9c740df0) at
/home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:309
No locals.
#6 0x008c4694 in execute (op_array=0x1dce4e0) at
/home/derick/dev/php/php-5.3dev-gc/Zend/zend_vm_execute.h:87
execute_data = {opline = 0x1e1b428, function_state = {function =
0x1e17c70}, fbc = 0x0, called_scope = 0x0, op_array = 0x1dce4e0, object =
0x1d7f670,
Ts = 0x7fff9c740188, CVs = 0x7fff9c740140, original_in_execution = 1 '\001',
use_heap = 0 '\0', symbol_table = 0x1e5fea0, prev_execute_data =
0x7fff9c741450,
old_error_reporting = 0x0}
To reproduce, run the Template tests of the eZ Components:
# mkdir ezc
# cd ezc
# svn co http://svn.ez.no/svn/ezcomponents/trunk
# svn co http://svn.ez.no/svn/ezcomponents/scripts
# ./scripts/setup-env.sh
# php UnitTest/src/run-tests.php Template
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Wed, 5 Dec 2007, Stanislav Malyshev wrote: To clarify I meant there's a tri-state (not compiled in, compiled in but collection turned off, compiled in but collection turned on). My recommendation was to always compile it in but to keep collection turned off by default. Do I understand it right that being compiled in, turned on and turned off have the same performance implications (slightly slower, a little bit more memory) and the difference is mainly stability-wise? Yeah - atleast, that's how David's original patch behaved. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Dropping Namespace
On Tue, 4 Dec 2007, Gregory Beaver wrote:
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
No, use should not allow this. Take the following example:
?php
namespace blah;
use DomDocument as test;
class DOMDocument { }
$dom = new DOMDocument; //
$dom-loadXML('booksbooktitleblah/title/book/books');
$s = simplexml_import_dom($dom);
echo $s-book[0]-title; // blah
?
Besides this being a *big* WTF factor (why is my internal class
suddendly doing something else?) simplexml will horrible fail in this
case.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Tue, 4 Dec 2007, Stanislav Malyshev wrote:
following some discussions on the list (re. multiple namespaces in file) as
well as a short discussion on IRC regarding not being able to do
use yeti::xml::DomDocument as DomDocument; - I do not see any point in
having
You mean like ability to override existing classes? I think it could be done
but I don't see it as a good idea - it probably would lead to some weird
programming mistakes.
Of course, I think allowwing this is a really bad idea - which brings me
to the main point of this argument:
1. As it is impossible to do use XXX as NativeClass we get to the
point
where we'd have to namespace new internal native classes
otherwise we might introduce BC breaks. AFAIK, we've always said that
There's very easy solution to this, if it ever becomes a problem - using
two-component names.
And that is exactly what I think we should not do. PHP reserves the
global scope. period. That means that (core)extensions should not have
to deal with all sorts of namespace clue or other tricks just because
some people like a misguided implementation of namespaces. The idea of
namespaces is to prevent collisions in USER land code, not turning
internal PHP classes into a pile of goo.
3. We keep bickering over using { } or not, multiple namespaces in a
file or not... etc. I understand that people want more flexibility,
but also we need a *simple* to explain implementation. With the
That's why not all flexibility gets in.
- You can't stick multiple namespaces in one file
You are not supposed to unless you using it as performance solution, which is
rather dubious practice anyway.
You're not supposed to put a count($array) inside your for loop either.
I don't quite understand why allowing multiple namespaces is such a big
issue, however - it won't solve the naming collision issue.
- Unlike other constructs in PHP that mark executable blocks,
namespaces don't use { }.
That's because namespaces are not executable blocks.
Neither are classes.
4. What is wrong with simple prefixes in the first place? Both PEAR_*,
Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
'namespaces'. We could optionally create a registry on php.net for
this to avoid conflicts.
What is wrong is names like
PEAR_DB_Data_Database_Module_Adapter_Implementation_Interface_Exception_Information_Collection_Element.
When you write a code that uses such names, you really don't want to repeat
all the thing every time.
No, but, do you really need to have such long names? And besides that,
you *have* to keep repeating them in every file you'd want to use them -
which means you actually have to type *more* in some places. So this
argument is kind of lame.
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not, and for
myself
Yes, they are.
Just saying Yes, they are is not a very good argument - actually, it's
not an argument at all.
(and most likely my work projects) I would have to decide not to go with
namespaces, but instead stick with the 3 letter prefixing. Something that I
Well, the loss is all yours :)
Actually, it's exactly the opposite, as I avoid naming colissions
(point 1), I don't need to import every class I want to use (point 2),
and can group all my classes together in one file (point 3).
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
On Wed, 5 Dec 2007, Andi Gutmans wrote: Yes that's basically true although Dmitry can probably elaborate. I believe if the collector kicks in there'll also be a bit of a slowdown but my main concern is to be able to turn it off because of stability. As you can see with the update patch it seems performance is quite good. From what I can see, the patch doesn't actually work... it just crashes. Did you have a look at that yet? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Thu, 6 Dec 2007, Antony Dovgal wrote: On 06.12.2007 11:21, Derick Rethans wrote: On Wed, 5 Dec 2007, Andi Gutmans wrote: Yes that's basically true although Dmitry can probably elaborate. I believe if the collector kicks in there'll also be a bit of a slowdown but my main concern is to be able to turn it off because of stability. As you can see with the update patch it seems performance is quite good. From what I can see, the patch doesn't actually work... it just crashes. Did you have a look at that yet? To be honest, I can't see any crashes using standard PHP test suite. That doesn't surprise me, as none of the tests there run really complicated code. Do you have a reproduce case or something? Sure, it was in my original mail, but here it is again: To reproduce, run the Template tests of the eZ Components: # mkdir ezc # cd ezc # svn co http://svn.ez.no/svn/ezcomponents/trunk # svn co http://svn.ez.no/svn/ezcomponents/scripts # ./scripts/setup-env.sh # php UnitTest/src/run-tests.php Template regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Thu, 6 Dec 2007, Dmitry Stogov wrote: Derick Rethans wrote: On Wed, 5 Dec 2007, Andi Gutmans wrote: Yes that's basically true although Dmitry can probably elaborate. I believe if the collector kicks in there'll also be a bit of a slowdown but my main concern is to be able to turn it off because of stability. As you can see with the update patch it seems performance is quite good. From what I can see, the patch doesn't actually work... it just crashes. Did you have a look at that yet? The GC patch passes the whole php test-suite with the same bugs. The fact that it crashes on some script doesn't mean that the patch doesn't actually work. That doesn't mean it works better for me than the old one either, where I couldn't get it to crash at all ;-) Anyway, did you try to reproduce it with the instructions that I provided? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Thu, 6 Dec 2007, Dmitry Stogov wrote: Derick Rethans wrote: That doesn't mean it works better for me than the old one either, where I couldn't get it to crash at all ;-) Anyway, did you try to reproduce it with the instructions that I provided? Yes I did. I'm looking into the crash. I tested the updated patches now, it it's much better. I do however still get an error: Template: ezcTemplateRegressionTest: ../home/derick/dev/php/php-5.3dev-gc/Zend/zend_hash.c(668) : ht=0x3cc79338 is being destroyed but only after running *lots* of tests[1]. I'll try to rerun it in GDB to see whether I can get a backtrace, or through valgrind. [1] ~/dev/php/php-5.3dev-gc/sapi/cli/php -dzend.enable_gc=1 UnitTest/src/runtests.php -c /home/httpd/html/report -D sqlite://:memory: regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thoughts on Feature Request - Arithmetic
On Fri, 7 Dec 2007, Nathan Rixham wrote: In-Built PHP Functions for parsing of basic arithmetic and if possible fraction to decimal and decimal to fraction $arithmetic_string = 3*5; echo arith($arithmetic_string); // returns float 15 What's wrong with eval? ?php eval( '$res = 3 * 5;' ); echo $res, \n; regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
On Thu, 6 Dec 2007, Gregory Beaver wrote:
I've been thinking a *lot* about your provocative email in the past
couple of days, and have come to a different conclusion from my original
reply (which, as a reminder stated I saw no problem with removing
namespaces as long as we kept the import facility to alias classes via
use). After a few hours of thinking practically about the
implementation, I realized that this would be impossible for the same
reasons as your first argument. So, I set out to find a solution that
keeps namespaces and solves the problems.
Right, that was the idea behind the mail :) As yours is pretty long, I'm
only going to respond to the main points.
1) recommend all global non-namespaced code that wishes to import
namespaced code via use Namespace::Classname add a namespace
__php__; at the top of the file, and that the __php__ namespace be
reserved for use by end-user applications.
2) use Name::*; is technically impossible without some kind of
autoloading mechanism, but can be reasonably approximated by importing a
long namespace name as a shorter one. use PEAR2::Really::Long::Name as
a; then allows referring to PEAR2::Really::Long::Name::Classname as
a::Classname, and PEAR2::Really::Long::Subnamespace::Classname as
a::Subnamespace::Classname.
Yeah, I know... I don't really care about this myself anyway - it's just
something that I heard in discussions.
[snip]
Detailed answers:
Derick Rethans wrote:
1. As it is impossible to do use XXX as NativeClass we get to the
snip
extension (DateTime, DateTimeZone). However introducing the new class
DateTimeSpan might break people's code that do things like:
?php
use myNamespace::DateTimeZone as DateTimeZone;
?
This is indeed the biggest problem. However, it only exists in the
global namespace (non-namespaced code). An example script using the
non-existing hypothetical PEAR2::DateTime class:
?php
include 'PEAR2/Autoload.php';
use PEAR2::DateTime; // fatal error - use name conflicts with internal class
$a = new DateTime;
?
However, the answer is simple and elegant. PHP applications that take
advantage of namespaces should use a namespace *in the application
global code* that is reserved for application code, like __php__.
?php
namespace __php__;
include 'PEAR2/Autoload.php';
use PEAR2::DateTime;
$a = new DateTime; // $a is an object of class PEAR2::DateTime after
autoloading, or if a previously included file has declared class
DateTime in namespace PEAR
?
Note that the only difference here is the addition of 1 line of code at
the top of the file. On the same token, this code:
?php
namespace __php__;
$a = new DateTime; // $a is an object of class ::DateTime
?
works as expected, accessing the internal DateTime class directly.
In other words, 1 line of code is needed to take advantage of
namespace's full protection and ability to import conflicting class
names into the global (in this case unqualified, not containing :: in
the name) scope, while at the same time preserving BC with existing code
(no modification needed beyond addition of namespace __php__;).
I recommend that the manual specify this convention, and will happily
take on the documentation of it.
2. You have to import every class yourself. You can currently not do:
use myNamespace::* as *; // or similar syntax
[snip]
There are ways of simulating use myNamespace::* as *; that are almost
as complete and are actually better for long-term maintenance. For
instance, let's say you want to use several classes from
PEAR2::Ultra::Long::Package::Name. You don't need to use each class
individually, you can import the entire namespace:
?php
namespace __php__;
use PEAR2::Ultra::Long::Package::Name;
$a = new Name::ExampleClass;
$b = new Name::SecondThing;
$c = new Name::ThirdThing;
?
Sounds like a good idea.
I have no strong opinion on {}, but I do see a compelling argument in
favor of not using {} for performance reasons if you're only going to
use 1 namespace per file except in extraordinary circumstances.
The only thing that in the case you *have* a multi-namespace file, using
braces would editors allow to the start and end of a namespace easily
(f.e. VIM's %).
A larger danger is this example:
?php
namespace foo;
echo strlen('hi');
include 'maliciousfile.php';
echo strlen('hi');
?
maliciousfile.php:
?php
namespace foo;
function strlen($a)
{
// do bad stuff
echo I'm evil
return ::strlen($a);
}
?
The above script outputs 2I'm evil2 - foo::strlen() is called for the
second call to strlen().
I thought only constants and classes could be parts of namespaces?
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace improvements to be committed very soon - final review
On Wed, 12 Dec 2007, Stanislav Malyshev wrote: because it's impossible to discuss anything on internals without the noise coming from outside..? Could we finally make this list read-only for every one but the @php.net people? I get enough spam already, spam from this list is not something everyone should suffer from. That's not the spam question. Talking directly to the person(s) is and would always be better than sending mails to a public list, from a ton of aspects. I see no reason to close the list, but I wouldn't expect all the discussions to happen *only* on the list. Of course, important things need to be discussed on the list, and they are. Although I don't really care about this specific issue, I do think that all the spam on the list drives people quicker to private discussions. I do think that in most (if not all) cases where e-mail is used to discuss PHP issues, the lists should be used. Especially when it's about redoing, say, a database abstraction layer. Private discussions are not a good idea, for just as many reasons as you probably can up with for saying that sending mails to the public list is not a good idea. But this is an Open Source project, and transparency is very important. Lately this has been slipping away, which I think is very sad. To to get back to the point of the noise on the lists - it's getting out of hand, and I am afraid that if we don't solve this any time soon, the lists will be useless for any sort of decent discussion and promoting even more secret cults. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
Hei, now some patches by Greg and Dmitry made it into CVS, some of the things in my mail have been resolved, however, we still need to come up with a solution to the 1st and most important issue: On Tue, 4 Dec 2007, Derick Rethans wrote: 1. As it is impossible to do use XXX as NativeClass we get to the point where we'd have to namespace new internal native classes otherwise we might introduce BC breaks. AFAIK, we've always said that PHP reserves the globals space for it's own use (see also: http://www.php.net/manual/en/userlandnaming.rules.php). In case we do add new classes (an example could be DateTimeSpan), they should of course follow the same format as already existing classes in the extension (DateTime, DateTimeZone). However introducing the new class DateTimeSpan might break people's code that do things like: ?php use myNamespace::DateTimeZone as DateTimeZone; ? feature versions of people would then show: Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument because the name is already in use. It would be silly to require to have to do this: - Create a class PHP::Date::TimeSpan - In your scripts: use PHP::Date::TimeSpan But with the current implementation, this seems to be the only non-BC breaking solution. If we chose *not* to require this silly namespacing of internal classes, users instead have to do this: ?php use myNamespace::DateTimeZone as myDateTimeZone; ? Basically prefixing the classnames... This you can already do just fine without namespaces. I know Greg has some ideas with __php__ as recommendation, but I find it a bit clumsy still. Perhaps Greg can summarize how it will address the above issue? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Fri, 7 Dec 2007, Dmitry Stogov wrote: all your tests passed for me yesterday with memory_limit=1G. May be it's some fresh non GC related bug :) Try the same test with -dzend.enable_gc=0 and with unpatched PHP. I would very interested in this bad test case, if it's really related to GC. I tried to run it, but unfortunately my machine ran out of memory before it (that includes a full swapspace). I'd need access to a machine which has more memory than I have for this (4gb minimal). If you have such a machine, perhaps you can try yourself? Instead of running just the Template tests, I ran all of them: ~/dev/php/php-5.3dev-gc/sapi/cli/php -dzend.enable_gc=1 UnitTest/src/runtests.php -c /home/httpd/html/report -D sqlite://:memory: For -c to work, you will need xdebug installed though - I tried without but got the same issue. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Thu, 13 Dec 2007, Dmitry Stogov wrote: You test are enormous, but than you anyway. :) I've found and fixed the problem. Now your test suite is passed with the following results: PHP_5_3: Tests: 7706, Failures: 45, Errors: 807, Skipped: 347 With GC: Tests: 7706, Failures: 45, Errors: 804, Skipped: 347 I've no idea why GC fixes three tests. (I can send you logs if you like) Yes, I'd appreciate that. And thanks for running them! Could you share the updated patch as well please? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] The last PHP 4 release
Hello! As we all know, PHP 4's general releases will stop being made at the end of the year. We've two weeks until then, and I think it'd be a good idea to wrap all latest fixes up into PHP 4.4.8. I am planning an RC for next thursday - unless somebody has a strong argument against this. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tokenizer tests
On Fri, 14 Dec 2007, Raghubansh wrote: kraghuba okay, I upgraded you. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tokenizer tests
On Fri, 14 Dec 2007, Raghubansh wrote: Would it be possible to upgrade me so that i can commit these tests. I have been writing committing phpt testcases for testing strings, arrays, files, etc functions. What's your CVS id? regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Thu, 13 Dec 2007, Derick Rethans wrote: On Thu, 13 Dec 2007, Dmitry Stogov wrote: You test are enormous, but than you anyway. :) I've found and fixed the problem. Now your test suite is passed with the following results: PHP_5_3: Tests: 7706, Failures: 45, Errors: 807, Skipped: 347 With GC: Tests: 7706, Failures: 45, Errors: 804, Skipped: 347 I've no idea why GC fixes three tests. (I can send you logs if you like) Yes, I'd appreciate that. And thanks for running them! Could you share the updated patch as well please? I'd like to play with it / test it - could you put the patch somewhere please? And also the test logs as I am interested in why the GC patch fixes things :) regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Wed, 5 Dec 2007, Derick Rethans wrote: On Tue, 27 Nov 2007, Wez Furlong wrote: All will be revealed soon. Just wondering what sort of timeframe you mean with soon... any idea? We're atleast another week futher along without any news. I find this getting more and more disgusting. What is the plan? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Mon, 17 Dec 2007, Dmitry Stogov wrote: Didn't I send it to you? Maybe, maybe not :) I couldn't find it atleast. I just tried to apply this to PHP 5.3, but it gives lots of failed chucks... Are you sure this is the one against 5.3? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Tue, 18 Dec 2007, Dmitry Stogov wrote: Derick Rethans wrote: On Mon, 17 Dec 2007, Dmitry Stogov wrote: Didn't I send it to you? Maybe, maybe not :) I couldn't find it atleast. I just tried to apply this to PHP 5.3, but it gives lots of failed chucks... Are you sure this is the one against 5.3? Probably I've changed ZE after the patch was done :( I'll rebuild it, but not today. Maybe we just should put it in cvs then? Then we won't have this issue and other people can test it more easily as well. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Will pay for fixes for bugs in PDO/PDO_ODBC
On Tue, 18 Dec 2007, Travis Raybold wrote: I've been trying to find someone who could help me with a fix for a few bugs in PDO_ODBC, and had no luck so far. I am more than happy to compensate someone for the time spent fixing these bugs. Unfortunately it is not that easy as it seems. For some reason the pecl/pdo_odbc and php-src/ext/pdo_odb directories are locked out for the normal PHP team and thus we can't commit to it. The comment in the rights file says: # DB2, SDO, IDS have tighter restrictions, so that IBM are not overly # legally encumbered. If you have contributions for these two extensions, # please contact the lead developers. This is a temporary measure until # we can put in place a more general process. It has been in this temporary situation since June 2005 :-/ regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
On Tue, 18 Dec 2007, Andi Gutmans wrote: Derick Rethans wrote: Maybe we just should put it in cvs then? Then we won't have this issue and other people can test it more easily as well. The only problem with that is what if people get bad benchmarks/results and we want to pull it out? It kind of defeats the purpose to do this in a more structured way. Want us to commit it to a branch? PHP 5.2.x? Neither of those solve the merging issues, so no, not to a branch or 5.2. It should just go to HEAD and PHP_5_3. *If* it seems to be really bad, we can always revert it later. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
On Tue, 18 Dec 2007, Andi Gutmans wrote: Derick Rethans wrote: On Tue, 18 Dec 2007, Andi Gutmans wrote: Derick Rethans wrote: Maybe we just should put it in cvs then? Then we won't have this issue and other people can test it more easily as well. The only problem with that is what if people get bad benchmarks/results and we want to pull it out? It kind of defeats the purpose to do this in a more structured way. Want us to commit it to a branch? PHP 5.2.x? Neither of those solve the merging issues, so no, not to a branch or 5.2. It should just go to HEAD and PHP_5_3. *If* it seems to be really bad, we can always revert it later. Uhm I meant 5.3. I guess we can commit it but as you know, reverting this kind of stuff later is a headache people don't like doing. Life's not always easy ;-) regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Will pay for fixes for bugs in PDO/PDO_ODBC
On Tue, 18 Dec 2007, Wez Furlong wrote: Your statement is not accurate: http://cvs.php.net/viewvc.cgi/CVSROOT/avail?r1=1.1200r2=1.1201 This should not be a blocker to anyone that wants to take this up. Missed that it was removed already. However, having a restriction in the first round does make people lose interest in specific bits of extensions - this is also why I am against any sort of restriction of committing on any bit of code inside the PHP core distribution. Anyhow, if anyone does want to take Travis up on his offer, you'll need the attached patch. JFYI: Mail.app is broken, please add attachments as attachments instead of dragging it in - it splits a normal mail up in two, so I almost missed this part: PS: More on PDO soon; it has not been forgotten despite sickness, work and so forth. Things like that happen, but it would have been *much* more proper to bring those things up *before* actually implementing something that many seem to be quite everse against. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Tue, 18 Dec 2007, Rasmus Lerdorf wrote: Ilia Alshanetsky wrote: Putting it into CVS into a good idea, but lets create a revert point via a tag, so we can always easily undo the patch if need be. Making sure it is ifdef'ed nicely would let us leave it in CVS until we get it right and if it causes problems for some people they have a way to build PHP without it. And yes, that means their build won't be binary compatible, which is fine and no different from them trying to revert the patch themselves. Both ideas sound like a good plan to me! regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Wed, 19 Dec 2007, Dmitry Stogov wrote: Derick Rethans wrote: On Mon, 17 Dec 2007, Dmitry Stogov wrote: Didn't I send it to you? Maybe, maybe not :) I couldn't find it atleast. I just tried to apply this to PHP 5.3, but it gives lots of failed chucks... Are you sure this is the one against 5.3? updated patch. Great, testing it now! regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Wed, 19 Dec 2007, Alexey Zakhlestin wrote: On 12/19/07, Dmitry Stogov [EMAIL PROTECTED] wrote: updated patch. got an error during linking phase /usr/bin/ld: Undefined symbols: _gc_globals_id _gc_globals_ctor _gc_zval_possible_root _gc_collect_cycles _gc_init _gc_reset _gc_zobj_possible_root collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 You have to re-run buildconf, it adds a zend_gc.c file. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4.4.8RC1
Hello! I packed PHP 4.4.8RC1 today, which you can find here: http://downloads.php.net/derick/ Please test it carefully, and report any bugs in the bug system, but only if you have a short reproducable test case. If everything goes well, we can release it somewhere in the first week of 2008. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.4.8RC1
On Thu, 20 Dec 2007, Marcus Boerger wrote: Hello Derick, to stick with our announced plan, can we release this in 2007? That would be exactly in one week, on the 27th then. I prefer doing it just in the new year cause all the sysadms are back to work then. I think Jan 3rd is still acceptable :) regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions instead of Fatal Error when calling non existent method?
On Mon, 31 Dec 2007, Fredrik Holmström wrote: What I would like to argue/request is that there should be a way to get an exception thrown when you call a non existent method on an object, since it's not possible to catch E_ERROR with a user defined function using set_error_handler() I can't see anyway to accomplish this in the current implementation? E_ERROR should during normal runs of your program *never* be hit in the first place. If it is something critical that still can be handled, E_RECOVERABLE_ERROR should be used inside PHP. If that is not the case, please let us now and we can address that. As for the calling undefined methods, __call() is your friend. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4.4.8 Released!
Hello! The PHP development team would like to announce the immediate availability of PHP 4.4.8. It continues to improve the security and the stability of the 4.4 branch and all users are strongly encouraged to upgrade to it as soon as possible. This release wraps up all the outstanding patches for the PHP 4.4 series, and is therefore the last normal PHP 4.4 release. If necessary, releases to address security issues could be made until 2008-08-08. A separate release announcement is also available. For changes in PHP 4.4.8 since PHP 4.4.7, please consult the PHP 4 ChangeLog. Release Announcement: http://www.php.net/release_4_4_8.php Downloads:http://www.php.net/downloads.php#v4 Changelog:http://www.php.net/ChangeLog-4.php#4.4.8 regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Stanislav Malyshev wrote: When the type hint says I want an integer, then only integer should be accepted; no casting should be done. It may give predictable results Why people that want Java just don't use Java I wonder? PHP never was a strict static typed language. Broken record perhaps? I am getting a bit tired of this just use Java argument, it's perhaps even a bit arrogant. From what I read there is plenty of people that want type hints for static types - there's a few patches out there, it doesn't slow down the general case. So why should we *not* add it? (And yes, I changed my mind) regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Sam Barrow wrote: Thank you. As long as a feature is useful, why not add it? With that statement I don't agree though. It needs to be usefull for a more general public, and not introduce a huge performance loss for example. Derick PS: Top-posting is considered evil on a mailinglist. -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Stanislav Malyshev wrote: I don't get it. We already have type hinting, just not for scalars. The Type hinting for scalars is different because it disables one of the features of PHP language - conversion of scalar types into each other. It doesn't disable this. It's still there if you want it. If you want slightly more control, you can have it too. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Sam Barrow wrote: It doesn't disable type conversion unless you specifically tell it to. Plus the fact that if it issues an E_WARNING, your application will not necessarily stop execution. Stop right here for a moment. Type hints currently throw an E_RECOVERABLE_ERROR, for obvious reasons. That means, that scalar type hints should do so as well - *without* auto conversion. We should not make this inconsistent or we really fucked it up. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 3 Jan 2008, Sam Barrow wrote: On Thu, 2008-01-03 at 22:37 +0100, Markus Fischer wrote: Of course, Jochem, you're right. Exceptions would be nice. WrongArgumentException, InvalidWhateverException, ... That would be very nice. The full blown suite of exception error handlers could be a future project, depending on code contributors and community support. As for my patch, I think we can all agree on E_WARNING. Definitely not. Type hints now throw E_RECOVERABLE_ERROR, and that should be the same for any other typehinting system that we add. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
On Wed, 9 Jan 2008, Joe Orton wrote: It's a bit of a maintenance headache for distributions when packages include their own copy of the timezone database, since this needs to be updated frequently. There is a PECL extension to provide those updates: http://pecl.php.net/package/timezonedb It is a drop-in replacement to update the rules. I've prepared a patch to allow the timelib code to use the system timezone database directly; would something like this be acceptable, any thoughts? Quite a few actually. Notes: 1) I've not implemented timelib_timezone_builtin_identifiers_list() here since it doesn't seem to be used, is it there for third-party extensions? It could be implemented by iterating through the directory. It's not used (anymore). However, there is a PHP function timezone_identifiers_list that uses the index information to enumerate all entries. Your patch prevents this function from working as both struct elements index_size and index are set to 0/null. 2) there's no general way that I can find to obtain the database version, so I just invented a string here. Not having the version creates another problem, as the PECL timezonedb extension will then *always* override the builtin database. The extension uses the version number to see if the extension provides a later rules set. With your patch, this extra check will not work correctly anymore if PHP's built-in version is newer (which would happen if PHP got upgraded). Some other issues: - This patchs allows accessing any file on the filesystem (because the path is not sanitized). - Opening a file is less quick than having the data in memory. - The system's format of tzfiles does not necessarily have to be the same as the one that PHP reads. On my (Debian) system the tz provided data is already 64bit read. Once I update the extension to use this extra data, reading the system tz files won't work anymore. - It would be possible to use a wrong set of tzdata, resulting in bugs like http://bugs.php.net/bug.php?id=35958 The reason to bundle the database is to have a operating system independent source of tzdata, which is something that this patch destroys. I am because of this, and all the other issues, quite against adding this patch - especially because there is already a solution for this. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
On Wed, 9 Jan 2008, Cristian Rodriguez wrote: 2008/1/9, Ilia Alshanetsky [EMAIL PROTECTED]: The reason we do not use the system database is because it is inconsistent and likely is updated less frequently then the one included with PHP. please consider this patch as an alternative for us !! Why do you need this? There is the PECL timezonedb extension which is updated just as frequently. in anycase, you will probably find this patch included in distros anyway, because this particular feature causes a lot of unnecesary manteniance pain, distributions just update the system timezonedb in regular basis. Yes, and that means bye-bye to support on it. If everybody would patch PHP then how can we every support things? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
On Wed, 9 Jan 2008, Larry Garfield wrote: On Wed, 9 Jan 2008 17:14:29 -0300, Cristian Rodriguez [EMAIL PROTECTED] wrote: 2008/1/9, Derick Rethans [EMAIL PROTECTED]: Why do you need this? It is simple, even releasing an update for a particular extension, trigger the whole manteniance and QA in distributions, and it unneccesary work , when the system tz is used you have QA and mantain just one component, the timezone package. jfyi: in a complete distribution, there are only 3 components that has this highly questionable behaviuor, Evolution, PHP and JAVA all the other hundred of components do the right thing or at least offer an option just like the Joe's patch. If a PECL module can override PHP's built-in tz database with its own, shouldn't it be possible to write a PECL module that always overrides it and then stubs out to the system tz database? That sounds like an option just like Joe's patch that should work fine. Not really, as the patch has other issues as well, which are not addressed by just doing this. (f.e. the enumeration of identifiers). regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
On Thu, 10 Jan 2008, sean finney wrote: On Wednesday 09 January 2008 08:50:59 pm Ilia Alshanetsky wrote: The reason we do not use the system database is because it is inconsistent and likely is updated less frequently then the one included with PHP. Personally I think this patch would be great, and I will recommend it to the other debian php maintainers for review. Let me just remind you: This patch BREAKS functionality. It would certainly be a lot better than our current solution, where the timezone db has been ripped out of php and put into a seperate package which is managed outside of the stable release cycle (in the volatile release area). That is a silly approach, when we (the PHP project) already provide a way to update this without having to make hacks. Have a look at the PECL timezonedb extension. I understand that it may make the job of developing/releasing/supporting easier for you to bundle the timezone db (just like libgd, et c), but please consider the position of those who are responsible for maintaining not just your software but thousands of other projects' packages... wouldn't it be possible to at least make this some kind of compile-time option for those of us who do like the idea? It has very little to do with maintenance, actually, it is more work for us to maintain that extension. But apparently you didn't read my other mail or simply chose to ignore it. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] no read-only, no moderation, just a simple self-enforced checklist
On Thu, 13 Dec 2007, Gregory Beaver wrote: We don't need moderation, we don't need read-only. We need people to follow a simple common-sense checklist. It's either that nobody saw this mail, or chose to ignore it. Obviously, nothing changed and I'm getting sick and tired of all this crap on internals, so here once more: Before sending a message to php-internals, ask these questions of yourself: 1) am I angry? yes = do not send your message, do not pass go, do not collect $200. Wait until tomorrow. 2) do I need help developing C code for the core, understanding how to track down a bug, reminding about a forgotten/ignored bug, or writing tests? yes = send your message and be graceful, no = goto #3 3) do I know what I'm talking about? no = do more research and write later, yes = goto #4 4) why should my opinion matter to anyone else? not sure = investigate other people's opinions on the matter, potentially off-list or on irc for new perspectives first, sure = goto #5 5) for new features, do I have a patch? yes = send message, no = goto #6 6) do I have a specific suggestion for changing the conception of how a feature is implemented? yes = goto #7, no = delete your message and do more research 7) have I made it this far? yes = send your message :) A monthly auto-mailing of this checklist to internals@ for newbies would also be a good way to remind us old farts to be decent citizens. PHP could also use a clearly defined leader who can shut down acidic debate or a flame war before it gets out of hand, the RM for the soon-to-be-released version might be a good candidate since most discussion should (in theory) be about that code. Greg -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Sun, 16 Dec 2007, Derick Rethans wrote: On Wed, 5 Dec 2007, Derick Rethans wrote: On Tue, 27 Nov 2007, Wez Furlong wrote: All will be revealed soon. Just wondering what sort of timeframe you mean with soon... any idea? We're atleast another week futher along without any news. I find this getting more and more disgusting. What is the plan? Still no news, and another three weeks... regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Square brackets shortcut
On Thu, 10 Jan 2008, Hannes Magnusson wrote:
So you reject scalar type hinting because it isn't type casting and
can therefor confuses newbies - but scattering seemingly random
brackets around your code (to safe 5 key strokes) is obvious to users?
Noone would confuse this with named arguments?
Why can't I do function foo([] $array) {} ?
foo([]);
$var = [];
Is this really readable?
Are you really serious about this?
I have to agree with this. It looks all cool and nice and stolen from
another language. But in the long end, all this does is saving you 5
chars to type, and lose a hell of a lot readability in the meanwhile.
(In case it's not obvious: -1)
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Array syntax []
On Thu, 10 Jan 2008, Antonio Touriño wrote: The array() syntax to me screams function call, something that, You mean just like if(), for(), while(), foreach(), elseif() and... ? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
On Mon, 21 Jan 2008, Antony Dovgal wrote: 6 reasons why we must to get rid of The Switch ASAP Amen! Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PDO 2: Request for Comments
, and if the big vendors want to make money through the PHP project by making PHP connect to their products better, I don't see why they should not follow *our* rules instead of dictating their own. There have been plenty of occasions as well where code (tests, fixes) were already contributed by either IBM and Oracle anyway. I also have an issue with the license for the PDO parts. Although the FAQ writes correctly that there are some parts of PHP that do not fall under the PHP License, all of those parts have not been written *for* the PHP project specifically - they were always adopted from other sources. PDO is part of the PHP project, and should therefore not come with its own license that has to be OSI approved again. I hope that I didn't forget anything in this longish email, but it should be clear that I'm totally against having a CLA on any part of PHP. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() bug
On Fri, 25 Jan 2008, Stanislav Malyshev wrote:
Hi!
Right now, if json_encode sees wrong UTF-8 data, it just cuts the string in
the middle, no error returned, no message produced. Example:
var_dump(json_encode(ab\xE0));
var_dump(json_encode(ab\xE0\));
Both strings get cut at ab. I think it's not a good idea to just silently
cut the data. In fact, I think it is a bug caused by this code in
ext/json/utf8_to_utf16.c:
if (c 0) {
return UTF8_END ? the_index : UTF8_ERROR;
}
which inherited this bug from code published on json.org. It should be:
if (c 0) {
return (c == UTF8_END) ? the_index : UTF8_ERROR;
}
Now this is an easy fix but would lead to bad strings silently converted to
empty strings. The question is - should we have an error there? If so, which
one - E_WARNING, E_NOTICE? I'm for E_WARNING.
Also filed as bug #43941.
Any comments?
Like I mentioned before (I think), it should not return an empty string
of course because programmatically it's not possible to check for this.
As most of our functions return false in those cases, so should this
function.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
On Fri, 1 Feb 2008, Marcus Boerger wrote: * Develop a PECL CLA that can optionally be used for PECL projects. * If necessary, adapt the PHP License, so that it works nicely together with the CLA. * The projects that want a CLA can choose between the PHP License or LGPL. * Change the PELC web site so that projects can opt-in to using the CLA. * Arrange it so that projects cannot drop the CLA flag. * Add a user/CLA/project table to the PHP user database, and use this in CVS ACLs. * Create a new CVS module php-default. * Move all extensions that can be disabled and are not required for others to PECL. * Link everything under php-src plus a default selection of extensions to php-default. * Let us once and for all ban CLAs from php-src aka PHP core. * Start developing PDO as part of CVS module php-src. Sorry for not writing this earlier. So how does this idea sound? Not terrible good actually. ALl the things that mention a CLA should never come close to PHP or PECL in my opinion. If people want to develop non-open software they can use their own resources for it. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] Re: An Idea for PDO 2
On Sun, 3 Feb 2008, Steph Fox wrote: Well thanks to a separate PEAR channel, we have all the infrastructure easily setup to have a different place for users to pick up the code. Or are you more concerned about the CVS, than the distribution of the packages? I don't have concerns about a PECLA module utilizing the existing PECL infrastructure in any way. Do you? I do, as it requires maintenance from the PHP project for non-open source code. I find that a bit strange. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
On Sat, 2 Feb 2008, Steph Fox wrote: 1) Distribution woes need to end. With the work Greg's been doing lately on PHP_Archive/Phar, that's very close to being attainable now in the physical 'getting PECL'd extensions out to people' sense, but unless people are running CLI or CGI or have access to their own php.ini they still can't do much with those extensions. So we have to seriously consider how to recommend extensions to hosts, other than by shipping them with the PHP core. 2) Maintenance status needs to be part of the equation. 3) Stability needs to be part of the equation. 4) Appropriateness to a given PHP branch needs to be part of the equation. 5) CS and documentation need to be part of the equation. Thoughts? Yeah, my main concern is actually not with the one above, except for 2) perhaps. The brilliant thing to have everything in core, is that it gets checked out, updated, etc like all other standard parts. Becaus of this compile errors and other related issues are *quickly* discovered - this is especially important when it comes to OS-differences. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
On Sun, 3 Feb 2008, Steph Fox wrote: Everything else - the fashionistas (JSON, xmlreader/writer) and the downright useful for some but not all (fileinfo, json, com_dotnet, posix) and the quirky stuff (pretty much anything Sara came up with) - should be in PECL. I see another issue after reading this, and that is that it makes it much harder for users to depend on specific extensions just being always available by default. It's important for application distributers to have this core set of extensions to rely on. It's annoying enough that some distributions (gentoo, freebsd) already use --disable-all and their users then bugging us (or me) with you should check that SPL is enabled in your code. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() bug
On Tue, 5 Feb 2008, Richard Lynch wrote: On Sun, February 3, 2008 7:51 pm, Stanislav Malyshev wrote: Like I mentioned before (I think), it should not return an empty string of course because programmatically it's not possible to check for this. As most of our functions return false in those cases, so should this function. AFAIR false is not valid JSON, so it would break a lot of code. Also, I am not sure we should change json_encode to return false on whole structure if one of the fields contains invalid utf-8. [snip] Put partially decoded value somewhere in a variable to be accessed, so that the programmer can make an informed decision about what to do. We're talking about encoding here though... regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision
On Tue, 5 Feb 2008, Mike Willbanks wrote: I know they've been marked deprecated and all, but, really, what's the cost/penalty to having a couple functions around for legacy apps? Then we will continue to be at the same old issue of they exist, people will continue to use them and never move away from them. Err, no? magic quotes *itself* is removed - this is just the functions to check if it's enabled or not. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
On Wed, 6 Feb 2008, Steph Fox wrote: As with so many topics on this list, I have no authority to influence the outcome. I personally think they've all got rules to instantly delete my email (but that's cause I'm paranoid). That's rubbish Richard - in some ways you're the most important person on the list. Odd, eh? I think allowing the the hints and them to be enforced if E_STRICT is set is the way to go. Speaking as a -0, I tend to think that's a bit too close to a +1. But others may think otherwise. I still we should add simple static typehints (ie. just the types that we use in the manual) - and they should behave in the same way as the other type hints that we laready have. Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision
On Tue, 5 Feb 2008, Pierre Joye wrote: There is not really a need to discuss the removal again, that's why I ask for a simple vote: +1: remove them (as it is now in HEAD) -1: Restore them and always return FALSE (not 0) 0: I don't care, do what you wish, I never use them anyway I don't care that much, but I think it would matter if the functions just are there and return false (so -1). for set_magic_quotes_runtime(), if true is passed, it should still throw a fatal error, if false is passed it should not (or actually 1 vs 0). Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
On Wed, 6 Feb 2008, Sam Barrow wrote: On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote: I still we should add simple static typehints (ie. just the types that we use in the manual) - and they should behave in the same way as the other type hints that we laready have. True, but we have to consider the fact that we don't have enough support on that side. This is not some election campaign were you change what you believe in just to go get followers. So no, I will not take that into consideration. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 6 Feb 2008, Stanislav Malyshev wrote: So, what do you think on this? Don't care so much about it, as long as the defaults keep the same like they are now. Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
On Sun, 10 Feb 2008, Stanislav Malyshev wrote:
3) Add more values to INI parsing, namely:
${php.version} = 50300
${php.debug} = 0
${php.zts} = 0
${php.sapi} = CLI
What these would be used for?
The version one is atleast useful for me to load different variants of
xdebug without having to edit the php.ini config file all the time.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) /zend_compile.c zend_highlight.c zend_language_parser.yzend_language_scanner.l /tests heredoc_001.phpt heredoc_002.phptheredoc_003.phpt he
On Tue, 12 Feb 2008, Andi Gutmans wrote: It's really hard to remember this stuff. Maybe we should make the system actually validate the messages when they are committed and reject the commit when tags are missing. For commits where a certain tag isn't relevant we could have an explicit way to skip it e.g. [DOC-NONE]. At least that way it's in the back (and front) of people's mind :) Uh, no thanks. I am perfectly caple of remembering if I need to use a tag or not and am not looking for somebody to hold my hands. The question is more *what* tag to use... @doc would definitely help. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 13 Feb 2008, Stanislav Malyshev wrote: matching GET/POST. I think this should be cleaned up so that _REQUEST behavior would conform its use case. Attached is the patch that implements request_order .ini value. Comments? Yes... I didn't seem to see a default: + STD_PHP_INI_ENTRY(request_order, NULL, PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order, php_core_globals, core_globals) Which means that without this setting, nothing ends up in request. The default should be what it is now (GPC). The same is true for php.ini-dist - it should mention the default (still commented out, just like the rest) as GPC too. regards, -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 13 Feb 2008, Stanislav Malyshev wrote: Yes... I didn't seem to see a default: + STD_PHP_INI_ENTRY(request_order, NULL, PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order, php_core_globals, core_globals) Which means that without this setting, nothing ends up in request. The NULL means variable_order is used. php.ini-dist - it should mention the default (still commented out, just like the rest) as GPC too. Setting this as GPC gives wrong idea - recommended setting is GP, as C is useful only in very rare situations for special applications. Yes, that's why php.ini-recommended should have GP. However, php.ini-dist documents *the default* - which should be GPC, like it is right now. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Mon, 18 Feb 2008, [EMAIL PROTECTED] wrote: Thank you for your attention and I'm looking forward to hear your comments And thank you for this very detailed proposal, I wish most other feature proposals were like this. I like the concept, it seems to solve some of the problems we had to hack around now as well. I've two quick questions for you: 1. can traits be put in a file of their own (I assume so actually) 2. can traits be autoloaded? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] nettiquette on this mailinglist
On Fri, 22 Feb 2008, Olivier Hill wrote: On Fri, Feb 22, 2008 at 11:21 AM, David Coallier [EMAIL PROTECTED] wrote: Well well well, sorry everyone. I'm just too cool to follow the rules :) Just kidding, I guess I will change email client and apply my signature to myself as well :) I'm sure you will quote correctly next time.. won't you? :) Although like Pierre said, quoting badly is not such a problem. Yes it is a problem if you get lots of email. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4 Bug Summary Report
On Mon, 25 Feb 2008, Hannes Magnusson wrote: On Mon, Feb 25, 2008 at 10:00 AM, internals@lists.php.net wrote: PHP 4 Bug Database summary - http://bugs.php.net Should these still be sent out? I've just disabled them. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Trait aliasing syntax suggestions
On Thu, 21 Feb 2008, Stefan Marr wrote: jvlad schrieb: in other words, why to introduce such a new thing as trait instead of using classes and trait'ing them? I've introduced it as a separate notion from classes to avoid misconception and problems occurring from conflicting properties and constant definitions. And that is something we need, as I had a hard time parsing the previous example without this. Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: documentation collaboration toolchain
On Sat, 23 Feb 2008, Lukas Kahwe Smith wrote: Personally I prefer going with a wiki, because I do not have much affection with CVS for these kinds of documents (actually I do think that the README's should be in CVS, which is why I worked with Hannes on creating the current php.net/reST interface). I have put this document up on my wiki [12], and I will keep it uptodate. I'd go for RFC in CVS/Rest, and the todo's in a wiki. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
On Sun, 2 Mar 2008, Marcus Boerger wrote: However, we had to drop multibyte support as well as the encoding declare. Just wondering, why did you have to drop the declare(encoding=...) ? It's just ignored in PHP 5.x - and it is useful to have for migrating php 5.3 apps to 6. So can you atleast make the new parser just ignore this statement? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
On Mon, 3 Mar 2008, Marcus Boerger wrote: actually you get a message (E_COMPILE_WARNING) that this is not supported. Maybe we could turn this into an E_NOTICE though. No, I don't get any warning/notice/ whatever with PHP 5.3: [EMAIL PROTECTED]:~$ php-5.3dev -derror_reporting=65535 ?php declare(encoding=utf-8); echo foo\n; ? foo Please don't break this. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
On Mon, 3 Mar 2008, Stanislav Malyshev wrote: 4. We expect people to upgrade from 5.2.x to 5.3.x without changing their systems. Is it clearer why I think PHP 5.x and 6 are different and why I think ICU dependency in the 5.3 core might be a problem? FWIW... I also think that bringing in ICU in 5.3 so late in the cycle - or actually at all in 5.3 - is not such a bright idea. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating php_dirname() in 5_3, removing in HEAD
On Wed, 5 Mar 2008, David Coallier wrote: I'm talking about extension developers. We will all have to add yet another #ifdef for this function, in the implementation or to define php_dirname to keep the implementation clean(er). As it is good to clean up codes, I'm not sure to remove this function is a good thing. That's why I suggest removing it in 6, and deprecating it from now on. As 6 will break everything anyway. I go it but there is no easy to deprecate an internal function. Except to spare two #define php_(u)_dirname in HEAD, I still see no gain :) Perhaps it's time to make a compatibility extension with all those ifdefs everywhere and engine hooks. That's fine, as long as nothing breaks. I'm with Pierre on this one. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for opcode caches
On Fri, 7 Mar 2008, Dmitry Stogov wrote: The attached patch for PHP_5_3 is going to provide general solution to control some aspects of PHP compilation. It is absolutely necessary for all opcode caches to make cached scripts work exactly in the same way as non-cached. There's no attached patch. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strtotime() in PHP 5.2.3
On Wed, 12 Mar 2008, Krister Karlström wrote: But I still think that the best option would be if maybe strtotime() would be able to work with the default format returned by MS-SQL and just ignore the milliseconds even if they're separated by a colon and also allow the AM/PM format at the end? Or is Microsoft just wrong here..? :) Sure, we can support this. Can you file a feature request please? regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Patch for opcode caches
On Fri, 14 Mar 2008, Dmitry Stogov wrote: however in PHP_5_3 we even keep ze1_compatibility_mode. I'm not able to remove it. WHy not? It's quite broken anyway. Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Fri, 21 Mar 2008, Stanislav Malyshev wrote: You can't actually use the class name DateFormatter when you want pecl/intl to be in core. Date is the prefix for the already existing Date extension. I think we still can name it DateFormatter, especially if we plan (and we do, as I understand) to merge DateFormatter functions with ext/date in PHP 6, and we don't have any conflict now and we do not have any plans to have DateFormatter in ext/date (correct me if I'm wrong here). You're wrong. We can rename it later *if* it gets merged into ext/date, but you can't simply use a classname with a prefix that conflicts with something else. Merging it would most likely change API anyway. But if you have a better name for it - please propose it. Something that does not start with Date. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Fri, 21 Mar 2008, Tex Texin wrote: I admit to being unclear on why DateFormatter conflicts with Date. I'll have to read the manuals later. Seems rather limiting if all names beginning with Date are now verboten. That said: A) Derick, Shifu, Can you (or anyone) demonstrate the name conflict? I think it should have been caught by testing if it exists. I'd like to reproduce the problem. It's not only an issue for classes starting with Date actually. It's in the CODING_STANDARDS: http://cvs.php.net/viewvc.cgi/php-src/CODING_STANDARDS?view=annotate#l152 Classes should be given descriptive names. Avoid using abbreviations where possible. Each word in the class name should start with a capital letter, without underscore delimiters (CampelCaps starting with a capital letter). The class name should be prefixed with the name of the 'parent set' (e.g. the name of the extension). In this case, all of the classes in pecl/intl should start with Intl. The reason for this is to not ever have conflicts between different extensions. B) Name change proposals: 1) DatetimeFormatter 2) IntlDateFormatter Which is option 2. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Fri, 21 Mar 2008, Pierre Joye wrote: On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Stanislav Malyshev wrote: You can't actually use the class name DateFormatter when you want pecl/intl to be in core. Date is the prefix for the already existing Date extension. I think we still can name it DateFormatter, especially if we plan (and we do, as I understand) to merge DateFormatter functions with ext/date in PHP 6, and we don't have any conflict now and we do not have any plans to have DateFormatter in ext/date (correct me if I'm wrong here). You're wrong. We can rename it later *if* it gets merged into ext/date, but you can't simply use a classname with a prefix that conflicts with something else. Merging it would most likely change API anyway. I rather prefer to have this class (and related) within the ext/date extensions. It is the only way to have a consistent and working date/time API in php. Date/time formatting is part of this API. I've mentioned that from the beginning (and started experimenting a bit with it already as date_format_locale()), but apparently that's not the correct way. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
On Fri, 21 Mar 2008, Stanislav Malyshev wrote: But maybe the change is that now it is considered evil by an even larger amount of people. So far I saw four. I do not double I can find 5 people that like templates with short tags. I don't think I've ever said I don't like short tags. It's not the issue here. The issue is that allowing to change it during runtime adds more WTF to PHP. WTF factors are bad. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, 23 Mar 2008, Tex Texin wrote: Pierre, Marcus, et al. 1) The project started a year or so ago. A few of us from different companies had a strong need to see that PHP had international collation, formats, normalization, grapheme support, and other functions in a time frame nearer than php 6. The resulting intl extension has been out for a while, first with collation, then with some formatters. Stas made announces to the php-i18n list at least as early as July 17 (possibly earlier). The specs were posted to php-i18n and there has been discussion on the list over time. The manual documentation was announced by Stas for review to this list as well on Dec 4. So there has been opportunity for input on the specs and the project is above board. No one is deciding anything about PHP. There have been 300 downloads since Dec. so some people know about it. There have not been many requests for changes. I think the major problem is that because discussions about it happen off-list, there is not much exposure on what you're doing and thus little feedback. That's the whole problems with splitting off to a different list for something that you're targetting to include in the core. So I don't think it's that strange that there is now a large group of people being not-so-happy about what you're trying to do here. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, 23 Mar 2008, Steph Fox wrote: Few people want this extension to be moved to core, which means: every decision about this extension is deciding anything about PHP. Those 'few people' were actually in the majority when it was put to the vote. Yes development could and should've been made public all along, but the fact remains that intl offers damn useful functionality. I am not so sure. I see (in the feb-04 sources) just collator, formatter, locale, msgformat and normalizer - and dateformatter that should be integrated into the Date extension to avoid issues and confusion. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, 23 Mar 2008, Stanislav Malyshev wrote: Noone is arguing about the usefulness of the extension. We are arguing about how the maintainers of the extension are about to abandon it once it reaches -stable and the fact it doesn't even try to Hannes, wtf you are talking about? Nobody even thinks about abandoning it. To make matter worse Zend is once again trying to split the community into closed enterprise discussion lists and php.net discussions. The list is open for everybody working on a project. And everything was announced and comments solicited on php-i18n too. That's not the point. The point is that discussions for something you want to put in core happen on the core list as well. More exposure - more feedback - happier people. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, 23 Mar 2008, Lester Caine wrote: Derick Rethans wrote: On Fri, 21 Mar 2008, Pierre Joye wrote: I rather prefer to have this class (and related) within the ext/date extensions. It is the only way to have a consistent and working date/time API in php. Date/time formatting is part of this API. I've mentioned that from the beginning (and started experimenting a bit with it already as date_format_locale()), but apparently that's not the correct way. I think the question here is WHY would you want to format a date without using a date object? SO why is it wrong to have object formatting packaged with the relevant object? I may be missing something here, but if the idea is to standardise then surly we should be standardising and not creating tools for unnecessary alternatives? I'm still having to use my own Date alternative until we can finally draw a line under PHP4 compatibility - so lets not start opening more rabbit holes to compatibility :( Yeah, exactly what I'm thinking. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] BC break with php 5.2.6
On Thu, 27 Mar 2008, Marco Kaiser wrote: This means this was maybe a bug, that i allread talked about but its now changed so we should raise a notice about this. That will BREAK Many many apps out there. For example, PHPUNIT, ZendFramework, ezComponents. I've tested with eZ Components, but I do not see anything that breaks. Could you elaborate? However, perhaps we should delay this change to PHP 5.3 - changes like this in mini versions are annoying. Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_ini_parser.c fails to create in latest PHP6
On Mon, 31 Mar 2008, Antony Dovgal wrote: On 31.03.2008 01:49, Cristian Rodriguez wrote: you need to install re2c and run ./buildconf --force He's using snapshots, so that should not be required. I'd say somebody forgot to upgrade re2c on the snaps machine. Sure, that has not been done yet. Actually, it was not even installed. I installed 0.13.3 now. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- 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) /win32/build config.w32
On Mon, 31 Mar 2008, Marcus Boerger wrote: Hello Steph, this doesn't work! When allowing to wotk with 0.13.3 then you will end up in a broken .c. Since we have the stuff checked in there really is no need at all to rengeneerate them atm. I found out that it does not work, but it *HAS* to work for snapshots. Please either revert the changes to PHP, or make an re2c release that can generate proper files. Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /win32/build config.w32
On Mon, 31 Mar 2008, Marcus Boerger wrote: Monday, March 31, 2008, 5:09:23 PM, you wrote: On Mon, 31 Mar 2008, Marcus Boerger wrote: this doesn't work! When allowing to wotk with 0.13.3 then you will end up in a broken .c. Since we have the stuff checked in there really is no need at all to rengeneerate them atm. I found out that it does not work, but it *HAS* to work for snapshots. Please either revert the changes to PHP, or make an re2c release that can generate proper files. That is not going to happen if no one cares about creating zend multibyte tests. Or we decide on getting rid of that stuff. Because obviously no on ecares about it anyway. Huh? How hard is it to rolll 0.13.4 ? Then the dependency works, the snapshots, and nobody has to fuck with timestamps. IE: Everybody happy. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- 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) /win32/build config.w32
On Mon, 31 Mar 2008, Steph Fox wrote: this doesn't work! When allowing to wotk with 0.13.3 then you will end up in a broken .c. Since we have the stuff checked in there really is no need at all to rengeneerate them atm. Release 0.13.4, and I'll happily update it! Without that, it doesn't really make a lot of difference what I do - I'm just trying to save people from a wild goose chase. NB it'd be a better idea to have the re2c release before the changes in PHP in future... It's required for source snapshots to work. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /win32/build config.w32
On Mon, 31 Mar 2008, Marcus Boerger wrote: Monday, March 31, 2008, 5:09:23 PM, you wrote: On Mon, 31 Mar 2008, Marcus Boerger wrote: this doesn't work! When allowing to wotk with 0.13.3 then you will end up in a broken .c. Since we have the stuff checked in there really is no need at all to rengeneerate them atm. I found out that it does not work, but it *HAS* to work for snapshots. Please either revert the changes to PHP, or make an re2c release that can generate proper files. That is not going to happen if no one cares about creating zend multibyte tests. Or we decide on getting rid of that stuff. Because obviously no on ecares about it anyway. Huh, that does not make sense. If you have a version in SVN that can generate the correct files, how hard is it to make a release out of that? What does it have to do with other missing functionality? regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The jump operator
On Fri, 4 Apr 2008, Richard Quadling wrote: On 04/04/2008, Jani Taskinen [EMAIL PROTECTED] wrote: You're about year too late..or even more. Please, don't just this discussion now. Is there use case that can be used for the documentation? http://youngbloods.org/essays/argument_for_goto.html has an IMO good example. It's java code, but it shows how goto can help you get rid of nesting hell. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
