Andrey Hristov wrote:
It works like in_array() but checks whether all needles
are in the stack array.
Looking at the prototype:
bool in_array_all(mixed needle1[, mixed needle2], mixed haystack [, bool
strict])
I'd say if (and I'm personally -1) this is added it should be
bool in_array_all(array
Hi Andrey,
My personal feeling is that not enough people use this to make the pure
speed improvement worth a new function. I guess the list will decide...
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sterling Hughes wrote:
The problem with simplexml_xpath_query returning an array is that how do
you signify failure and an empty set. In order for you to have code
that uses foreach() it would need to return an empty set on failure in
order to avoid warnings.
My preferred solution would be
1)
Andi Gutmans wrote:
game to be doing so. We are in a feature freeze now so that we can get
RC1 out of the door hopefully by the end of the month, and it just
doesn't make sense to redesign the whole thing now.
Consider this: Judging from the comments on the list it seems to me that
a) people
Sebastian Bergmann wrote:
Log:
Added error mask to set_error_handler()
Patch by Christian Schneider [EMAIL PROTECTED]
zend_operators.c
e:\home\php\php5\zend\zend_operators.c(36) : error C2059: Syntaxfehler : ''
To avoid misinterpretation: My patch didn't involve zend_operators.c
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be more
dangerous than the performance benefit. Which, BTW, I estmate as pretty
minimal - code space is shared on all modern OSes anyway, so a little
I think that's a good point for leaving it the way it
Andi Gutmans wrote:
I don't even mind if --disable-all doesn't disable ext/standard but it'd
be nice that if we do a split to core/ and standard/ (I wouldn't go into
more granularity than that) that we could have a --disable-standard.
I see no problem if it's not included in --disable-all. It is
Rasmus Lerdorf wrote:
Yup, thousands of little servers with less than 100 httpd children on each
is how the biggest web load in the world is handled.
I completely agree and think this is the way to do it. The only point to
consider might be KeepAlive which binds processes without using any
Marcus Boerger wrote:
Further more i think we cannot fix it becasue the script mixes compile
time and run time. It tries something like selfmodifying code.
I agree that it should be disabled. If someone really, really wants to
do it they can still include/eval conditionally.
- Chris
--
PHP
Derick Rethans wrote:
I would like to see E_STRICT added by default otherwise things start out
getting way too complex.
As mentioned here on the list I added E_STRICT to the patch two days
ago, now I'm curious if someone with karma will apply it ;-)
- Chris
--
PHP Internals - PHP Runtime
Andi Gutmans wrote:
I disagree with Derick and I thought we agreed that the default would
stay E_ALL and not E_ALL|E_STRICT.
Oh, I misunderstood you comment then.
I don't really have an opinion on E_ALL vs. E_ALL|E_STRICT, as soon as
you and Derick sort it out I'll adapt my patch (or you can
Andi Gutmans wrote:
Why not make the default catch-all as E_ALL and add to the documentation
that the new E_STRICT option needs to be turned on explicitly?
Just using E_ALL would match error_reporting where the default E_ALL
does not include E_STRICT. Including E_STRICT would match the old
Moriyoshi Koizumi wrote:
1) Leave things they way they are now, giving everyone a partial
support for
multibyte string in fgetcsv() and 2-3 performance decrease in all
instances.
Of course this is my choice.
I'm not sure this is what you want because the words _partial_ support
seem to be the
Christian Schneider wrote:
A patch for PHP5 accomplishing this can be found at:
http://cschneid.com/php/php5/set_error_handler_reporting_parameter.patch
I updated the patch to keep a stack of the error_reporting level so
restore_error_handler works as expected.
- Chris
--
PHP Internals - PHP
ing.Martin Prásek wrote:
Know that, but when you _need_ it ?
It would have to be safe. Really safe. And I doubt that you could do it
without a lot of work. Especially from module maintainers. More than can
be put into it without delaying PHP5 another year.
PHP5 have integrated tidy so let
Derick Rethans wrote:
By browsing over it it seems that this patch looks wrong, as you forgot
to add E_STRICT to E_ALL in line 944 and it would also be better to use
zend_parse_parameters.
Thanks for your help on improving the patch.
I used E_ALL because that's what was proposed by people here on
Zeev Suraski wrote:
Sure there is. You may shut off (or otherwise configure) error
reporting site-wide, or application-wide, whereas you'd use the error
handler only in parts of the app/site.
No one keeps you from changing the error_reporting level at certain
points in your application so I
Lukas Smith wrote:
Sandbox ?
This would have to be done _very_ carefully to not leave a backdoor
open. PHP offers oh so many ways of accessing the system.
I guess one'd have to start with safe_mode with quite some functions
disabled and go from there. But...
BTW: if PHP wants to be the
Mike Ford wrote:
How about a new optional 2nd argument to set_error_handler?
Sounds like a good idea to me. Could be the mask of errors one wants to
get in the error handler.
So one could do
set_error_handler(handler, E_ALL); # Default, current mode
set_error_handler(handler,
Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans wrote:
It is when it's optional and the default is the current behavior.
Pardon me. Looks like PHP 3 behavior is still stuck in my brain...
No, you were right. A script using
set_error_handler(handler,
Daniel Convissor wrote:
I, and lots of people, need to worry about it. I write code that uses
I second that.
Adding an optional argument has the worst of both worlds. In order to
take advantage of it, one must lock your code into PHP 5.
In this specific case I can live with an optional
Lenar Lõhmus wrote:
But it's not good either stopping my error_handler from being called in PHP5
accordingly to error_reporting() value. This way I might not notice my
error handler isn't getting all calls it used to (depends on conf). So IMHO
silent behavior change is still worse.
Ok, now
Lenar Lõhmus wrote:
by their creators waiting to be downloaded. That script/project could use
custom error handlers and could somehow depend on PHP4's behaviour. You
never know.
My guess of the chance that this happens? I'd say about 1:2^42. This
script working without changes with PHP5? About
Derick Rethans wrote:
What in your world is broken behavior might be a feature for somebody
else.
I do *not* want to remove a feature, I want to add one which is missing
badly!
Do you actually _read_ what people write? *sigh*
Do you have any hard data to back those numbers up?
My sentence
Zeev Suraski wrote:
argument makes a great deal of sense. As a matter of fact, in practice
- you can easily get forward-compatibility. Just supply it in both PHP
4 and 5 - extra arguments are ignored anyway (just provide @ to make
sure of that).
Just checked it and no: set_error_handler does
Andi Gutmans wrote:
Anyway, I very strongly feel that an additional optional argument to
set_error_handler() is the right way to go.
Let's go this way!
A patch for PHP5 accomplishing this can be found at:
http://cschneid.com/php/php5/set_error_handler_reporting_parameter.patch
- Chris
--
PHP
Daniel Convissor wrote:
It's the custom error handler in pearcmd.php. PHP doesn't pay attention
to any error_reporting() settings when a custom error handler is
established. Then, error_handler() doesn't account for the new warning
level.
Is it just me or is this undesired behaviour? I noticed
Derick Rethans wrote:
It won't bork all scripts with a custom errorhandler if their default
action is to ignore core and other errors but only handle the ones they
should handle. I do agree that it should be mentioned in the changes
file though.
On the other hand you have to be very careful
Andi Gutmans wrote:
Yeah this is a known bug and will have to be fixed in RC1. It's not a
showstopper for B3.
Yes, this bug has indeed nothing to do with B3. I just though that PHP5
would maybe be the time to make set_error_handler finally usable.
In any case, I do think that the custom error
Derick Rethans wrote:
So you're suggesting to add another BC break here, without a really
good reason? :)
No, I'm suggesting a very minor BC break for a very good reason: To
render it useful, after all (-:C
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Andrey Hristov wrote:
Look like I am an weirdo :) with an web farm of servers which log
every NOTICE that appear. And even I think it was possible to catch
a fatal error that happens in a required file with the way the
error handler works now.
And what exactly keeps you from setting
Andrey Hristov wrote:
Good question. Having an error handling function becomes really
expensive if your code is not E_ALL-clean in a loop or something.
if you set a custom error handler you know what you are doing
and probably don't have such places in the code :)
No, that's where you are wrong:
Andrey Hristov wrote:
That's your view :)
Exactly.
E_NOTICEs exists for good not for bad. If one codes a simple web
interface it's ok for him to use
the autoinitialization but in 99.999% of the cases the user won't use
And that's _your_ view ;-)
[EMAIL PROTECTED]:/sample_project $ find -type f
Andi Gutmans wrote:
You can get it at http://cvs.php.net/~andi/
Errr, is it just me or is the directory empty? :-)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Oops, sorry, saw the follow too late.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
Why print and no echo? ;-) (Or was it the same again...)
I hope print and echo will be treated the same. It looks like right now
__toString() is never called automatically, I just updated from CVS and
I get Object id #1 for the example program.
BTW: The example in
Marcus Boerger wrote:
please try php-cvs version and report any problems (or dislike) as soon as
possible.
Neither a problem nor a dislike but I noted that __toString() is also
called on exit($obj);
Didn't check if there's more cases.
- Chris
--
PHP Internals - PHP Runtime Development Mailing
Markus Fischer wrote:
Since every man and his cow already gave a vote, I'll do so too and
vote -1 for theCapsStyle in PHP itself. However, I think e.g. the
DOM extension should be left at what the W3C suggested (other
extension my need exceptions too).
I agree with
Stig S. Bakken wrote:
For the next 18-24 months, we are going to have to deal with code
running in both PHP 4 and 5. Why not declare var an alias for
public, not throw E_STRICT for it and be done with it? If not this
issue will be a real PITA for PEAR users.
+1 from me (not that my vote counts,
Andi Gutmans wrote:
E_STRICT will be disabled by default. It is only meant for people who
want to be sure that they are using the recommended methods, and that
definitely includes not using var.
The problem is that it doesn't match the real world. People _are_ using
PEAR and people _are_ using
Marcus Boerger wrote:
I see all your concerns. But from my point of view pear has (of course) the
problem that it is written in php4 and for php4. So PEAR needs to address
the move towards php5 code anyway. An optional E_STRICT would help here
wouldn't it?
[My concern is that if E_STRICT warns
Andi Gutmans wrote:
Again, people don't have to use E_STRICT. I think having two new E_'s is
Why then introduce it at all? Or why not slightly change it to be useful
for a lot more people?
a bit of an overkill especially as there aren't that many things we
can add to them.
I think all of the
I'm not really sure on what's the best way to handle the string
conversion problem, as I haven't worked with SimpleXML yet. Andi's
examples on the other hand aren't convincing enough for me so here my
comments:
Andi Gutmans wrote:
a) include $obj; will not error out but convert the object to a
Jani Taskinen wrote:
I don't really understand how removing a deprecated function
would hurt anyone..doesn't all people test their scripts before
putting new PHP version into production?
You seem to be forgetting that the people in charge of the PHP
installation and the ones doing
Andi Gutmans wrote:
issues and many of them might be solvable (using the already existing
compatibility mode for object cloning or by other means).
Could we please, please, please have a way of cloning objects which
works in both versions? I'd like to use the new semantics as soon as
it's
Andi Gutmans wrote:
You can use the zend2.implicit_clone INI directive (change it at
run-time if you want at the beginning of the application).
But I do want to move my application to the new semantics, I think it is
much more reasonable than the PHP4 behaviour anyway (sadly enough my
request
Marcus Boerger wrote:
If i get you right you want to have __clone() for PHP4, too right? But
that's already to late.
That's what I was told when I was asking for ref on assignment for PHP4.
And now we have to go through this hassle for PHP5. I simply cannot
believe noone thought of this problem
Derick Rethans wrote:
Just use an auto_prepend which sets the implicit_clone option... no
problems then anymore.
*Sigh*
Looks like you're not reading my postings really.
This means your migration path to ref on assignement semantics is:
1) current code, copy (PHP4)
2) wait months for PHP5 to be
Björn Schotte wrote:
I think they solve the problem exactly the way Wez told you.
Which means everyone has to reinvent the wheel. Ok, fine with me.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
No, what I said was correct. As it is very unlikely that we create a new
PHP 4 minor version we CAN not at a new function as it's impossible to
modify source that has already been compiled on thousands of machines.
So no more bug fixes either? That's serious stuff and quite
Marcus Boerger wrote:
He doesn't say that. We are doing a lot of work on the QA front and of
course fix bugs and release new versions. But our policy is to introduce
Ok, I declare it a bug then so you can include it in the next bug fix
release. The point about not being able to compile it on
Matthias Nothhaft wrote:
declare_superglobal($_MYVAR);
Has one single superglobal $_APP (or $_USER or the like) already been
discussed? (Sorry Andi, couldn't find it in this list and didn't find
the 'engine2' list you were referencing at all).
I second Matthias that some sort of user-controlled
I'd like to see a clone() (or whatever name you want) function which
should exist in both PHP4 and PHP5 and allows to clone objects in a
compatible way.
Currently I'm using
function clone($object)
{
return (is_object($object) version_compare(zend_version(),
'2.0.0-dev', '')) ?
Sebastian Bergmann wrote:
http://www.sebastian-bergmann.de/PHP_Benchmark/
Any comments, feedback, corrections and additions are welcome,
You've done a good job but we basically only see two things:
a) PHP4 is an order of a magniture faster than PHP3.
b) PHP5 is about the same speed as PHP4.
Mike Robinson wrote:
The benchmark provides insight into changes in PHP speed between
versions, major and minor. IMHO that's useful information, nice
It tackles very little of PHP. One of the main changes of PHP5 (object
references vs. copying) is missing for example. Of course it could be
Andi Gutmans wrote:
I guess I think it'd be interesting to see what other's think. Also,
another point to check is if list() can also be converted into []
because having a hybrid wouldn't be too nice.
Having list() work the same way would be very sexy indeed:
[$a, $b] = [$b, $a];
To be honest I
Ok, I tried to just listen to what people are saying but this comment
went too far ;-)
Antony Dovgal wrote:
No, it looks like someone trying to turn PHP into Perl (or Python).
I'm just trying to improve PHP. And I write _a lot_ of PHP code, so I
have some idea about where the syntax could be
Antony Dovgal wrote:
do you agree, that $a[] = ''; and $a = []; look almost similar for newbies?
And they both deal with arrays. That's not confusing to me.
Why have $a[] = ''; then in the first place? You already have
array_push($a, ''). Or do you seriously think $a[] = ''; shouldn't be there?
Andi Gutmans wrote:
I don't believe in saving characters.
Agreed, it's not about saving characters (only).
Anyway, it's no biggy and if most people here think it shouldn't be
added then that's fine with me.
Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
couldn't figure
Marco Tabini wrote:
$a = [[1,2,3],[1=[1,3,2,2], a=[[1,2,3,4],4,[1,2]]];
$a = array(array(1,2,3),array(1=array(1,3,2,2),
a=array(array(1,2,3,4),4,array(1,2)));
What was your point again? ;-)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
George Schlossnagle wrote:
George (thinking [] is pretty but disliking alternative syntaxes)
Ok, let me recap my short visit on this mailing list:
1) Dangling commas in function calls were considered bloat
2) Adding the local vars to debug_backtrace() was silently ignored
3) A prettier array
Ard Biesheuvel wrote:
spell out your array definitions. The decision has been made a long time
ago to use the array() syntax. Adding alternatives adds nothing but the
I was under the impression that syntax changes are possible. Silly me.
Try/catch however are a fundamental extension to the
I propose to add an alternative (backward compatible) short array
creation syntax:
$a = [ 1, 2, 3 ]; and $a = [ 'a' = 42, 'b' = foo ];
It can also be used in function calls:
img(['src' = logo.gif, 'alt' = Logo]);
Reason behind this change: Arrays are used a lot and should therefore
have as
Gareth Ardron wrote:
$var = foo=1amp;bar=2;
To clarify:
You should use $var = foo=1bar=2; and then $var for header() but
htmlspecialchar($var) for your href:
- HTTP-Headers must not be html-encoded.
- HTML-Attributes on the other hand have to be html-encoded.
Even though most browsers work with
Ok, I worked out a patch which does not leak memory. I don't think
thread-safety is an issue here but if anyone with deeper insight into
Zend sees any problem with this patch, please tell me.
What's the process (and chance :-)) of having this included in a future
version of PHP? Should I also
Michael Walter wrote:
(the common) way of faking named parameters, you rely on a) hash lookups
at execution time (for _every_ call) and b) on manually dealing with
default values.
I'd even be happy to accept these two drawbacks but the ugliness of the
array() solution is what I'd like to get
Andi Gutmans wrote:
In this case I don't see the same advantage and I see a disadvantage in
readability and the possibility for PHP to give such an empty argument a
meaning in future (although I doubt that'll happen).
Ok, here the real-world example from our HTML generation toolkit:
table(
Hello everybody,
just joined the internals list (after being absent from php developers
lists for a while) so excuse my ignorance if any topic I bring up has
been discussed already. I checked the archives but couldn't find anything...
Proposal: Allow dangling commas in function call parameters.
501 - 568 of 568 matches
Mail list logo
