> From: Aegir Leet
> Either way, if you want a less strict language, that language already
> exists: It's the current version of PHP and you and everyone else who
> likes the way it works can keep using it.
For approximately 3 years. Please remember "end of life". We'd still be using
php5
> If we want PHP to be as easy as possible then $nullref->bar(),
> $foo->someUndefined(),
> new UndefinedClass etc shouldn’t be exceptions either - they can just be
> notices.
That's very different. Note that this code doesn't even generate a notice:
$x = null;
var_dump($x+1);
I'm joining
> ...
> 3. Putting your apparent personal bias against backwards compatibility
> aside - if P++ goes in the directions you're hoping for - towards giving
> you the goodies on your wish list, why would you care if PHP still existed
> without these new changes/features?
>
> Zeev
I just want to
On Sat, 2015-03-14 at 00:22 +0100, Bob Weinand wrote:
Am 14.03.2015 um 00:14 schrieb Zeev Suraski z...@zend.com:
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski;
On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote:
We are talking about something deprecated since 10 years, about the 1st
major release in a decade, something we will use for the next 12-14 years.
That is the point - PHP 4 constructors have NOT been marked as deprecated in
the
On 8 Jul 2014, at 15:48, Derick Rethans der...@php.net wrote:
I've just voted no for this, because it introduces a tiny BC break.
Now, I realize this is a tiny BC break, but it is just *those* that
drive people nuts when upgrading. There is so much non-public code - a
cursor check of Symfony
Some of us have rather large bodies of code written over 10-12 years
that make significant use of calling $this from incompatible
contexts (i.e. we know it's compatible, but php doesn't).
Most consider such use a sin.
Could there be a compromise that would allow us evildoers to continue in
our
On Mon, 2012-07-30 at 19:31 +0200, Gustavo Lopes wrote:
https://wiki.php.net/rfc/incompat_ctx
An RFC for deprecating and removing $this from incompatible context.
Comments are welcome.
--
Gustavo Lopes
I'm just a user, but I'd like to beg that the feature not be
removed, at least not
eval() does indeed set the response code to 500 upon failure.
Is that a bug? I'll file a report because I don't believe
leaving the response code at 500 is consistent with the
statement from the php.net page about eval():
If there is a parse error in the evaluated code, eval()
returns FALSE and
It feels like there is a bug in php somewhere. I'm trying to debug
this myself before filing a report and am in over my head. The
short version of my question may be How do I set a watch on
SG(sapi_headers).http_response_code in the gdb?
I think I need to debug it myself because I haven't been
[I'm afraid of getting flamed for how bad the code was in the example
in my first email. I've replaced the example in this email. The
rest is the same. The example still isn't great, but it's better
than before.]
It feels like there is a bug in php somewhere. I'm trying to debug
this myself
$x = null;
get_class($x) returns get_class($this) as of 5.3.
I don't recall seeing a discussion of this on the list and
I can't find anything about this change in the archives.
The documentation is currently self-contradictory...
Under Return Values:
Returns the name of the class of which object
Adding to John Crenshaw's list of reasons not to implicitly
treat strings as arrays in foreach loops... Please keep in
mind the following valid code:
$s = 'hello';
foreach ((array)$s as $x) {
var_dump($x);
}
The result is:
string(5) hello
That behavior can be handy. Hopefully, a BC break
On Mon, 2011-06-20 at 10:06 -0700, Stas Malyshev wrote:
Hi!
On 6/20/11 9:57 AM, Todd Ruth wrote:
Iterators are nice. Having a text_string_to_array function
would also be fine. For example:
$s = 'hello';
foreach (text_string_to_array($s) as $x) {
var_dump($x
I'm not arguing whether the following code fragment is good
or bad (it's certainly less than ideal), but given the recent
threads, I thought I'd show how I feel I've been encourage by
php to code:
?php
$x = array();
$y = 'something';
$temp = $x[$y];
$temp++;
unset($temp);
?
I'm not sure where
This thread inspired me to google for a POSIX to PCRE converter.
I found a thread from this list from 2002:
http://marc.info/?l=php-internalsm=103625548402350w=2
Ilia proposed a patch that would replace the ereg library
with code that would allow an ereg userland call to be
processed with the
On Wed, 2009-03-11 at 22:16 +0100, Olivier Doucet wrote:
Hello,
I posted the same topic on the general mailing list, but it appears this can
be posted here, as it is open to feedbacks and is about PHP implementation
of static functions.
I'm wondering if the following behaviour is a bug or
On Thu, 2008-05-08 at 20:28 +0100, Steph Fox wrote:
...
Does anyone have a good reason for keeping it switched on by default in PHP
5.3? Like, would switching it off by default break a lot of existing code,
given that most users are a bit beyond PHP 3 now?
Well, I can at least comment on
On Thu, 2008-05-08 at 22:58 +0200, Hannes Magnusson wrote:
On Thu, May 8, 2008 at 10:08 PM, Todd Ruth [EMAIL PROTECTED] wrote:
On Thu, 2008-05-08 at 20:28 +0100, Steph Fox wrote:
...
Does anyone have a good reason for keeping it switched on by default in PHP
5.3? Like, would switching
On Fri, 2008-05-02 at 23:52 -0400, Cristian Rodríguez wrote:
Todd Ruth escribió:
Most people don't care about floating numbers beyond a certain
number of digits.
That's the main flaw in your suggestion, most people.. the language
should be correct, do the real right thing.
Would
I'm afraid you'll find Pierre's response representative. The
php devs seem to consider the fact that a theoretically perfect
== doesn't exist to mean that the improvements that would
cover 99.9% of user issues with float == shouldn't be made.
It could be worse, however. At least the cast to
On Fri, 2008-05-02 at 11:41 -0700, Rasmus Lerdorf wrote:
Stefan Walk wrote:
And you'll quickly see that the cast to string before comparision is a
bad idea, because:
$ php -dprecision=1 -r 'var_dump((string)1.4 == (string)1.1);'
bool(true)
Having display settings affect comparisions
:
There is no bug here. Please read:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
-Rasmus
Todd Ruth wrote:
I'm thinking there must be a bug in the heart of php
causing this. I'll debug it, but I haven't looked at
php source code in a few years and would like a tip as
to which
corner now. Thanks for listening...
- Todd
On Fri, 2008-04-11 at 22:59 -0700, Todd Ruth wrote:
I'd take that as proof of a design flaw in having php
doing string to float comparison by casting the string to
float instead of the float to a string, but you've got
me - the documentation does
I'm thinking there must be a bug in the heart of php
causing this. I'll debug it, but I haven't looked at
php source code in a few years and would like a tip as
to which files are involved in evaluating ==. Here
is a fragment from my code and the output:
...
print pre\n;
var_dump($max);
I compiled 5.2.5 last night and noticed that it effectively breaks all
static calls which have no static keyword assigned in the function's
definition (sorry, a bit clumsy here).
How about waiting to break people's :: calls to non-static functions
until some number of releases
In case anyone is really excited about traits and traits
don't make it in soon, I'll point out that something similar
has been available in php for years. We've been implementing
traits based on the fact that $this has a different meaning
in php than in other languages. In php, $this is the
Would this be legal?
function f() {
return [ 1, 2 ];
}
$x = [ $a, $b ] = f();
In the end, would we have...?
$a = 1;
$b = 2;
$x = array(1,2);
I'm not trying to be positive or negative about the
syntax. I'm just testing somewhat edge cases.
- Todd
On Mon, 2007-02-05 at 10:06 -0800, Andrei
I'm not a voter, but I'd like to lobby for a fancier
E_STRICT...
E_STRICT is sounding more and more like runtime lint.
I very much miss lint. (I'm sure it's still around, but
I've been programming in only php for the last few years.)
A key feature of lint that made it usable was that you
could
Hooray! Thank you, Zeev! I'd nearly given up hope on ever moving
to a new version of php. (Actually, I'm still doomed for using $this
in static calls to an unrelated class, but every bit of avoiding
fatal errors helps.) Our code may not be OO, but it's definitely
php. ;)
Thanks,
Todd
On Wed,
On Thu, 2006-05-25 at 14:53 +0200, Marcus Boerger wrote:
There is no way you can write heavy oo using code that supports PHP 4
and PHP 5.2 without a version check every here and there, so i don't see
this as an argument. It is a fact that 4 and 5 have very different object
models.
Sort of.
PM 5/15/2006, Edin Kadribasic wrote:
Todd Ruth wrote:
I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6.
My sentiments exactly. OO purity/strictness do now work well with
PHP's main
On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
...
Side note: calling functions statically that do not have a static
modifier causes E_STRICT. Hello PEAR::isError()
This is of course going to be a fatal in PHP 6, but it is now the most
common E_STRICT I see in PHP4-based code.
On Mon, 2006-05-15 at 20:27 +0200, Marcus Boerger wrote:
Monday, May 15, 2006, 6:03:14 PM, you wrote:
On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
...
Side note: calling functions statically that do not have a static
modifier causes E_STRICT. Hello PEAR::isError()
This is
I'd been ignoring the curly braces thread, but then I grepped my
code and ... sure enough, I have curly braces that are used to index
into strings. I don't care about this philosophically, but it makes
me wonder about upgrade tools. I know I shouldn't ask this without
volunteering to do it
On Thu, 2005-11-17 at 16:47 -0800, Rasmus Lerdorf wrote:
Todd Ruth wrote:
...
It would be so wonderful to throw all my code at a tool that would
change everything that can be easily changed and give me a list of
spots I need to look at manually. A lot of the changes don't take
On Sat, 2005-10-08 at 21:57 +0200, Matthias Pigulla wrote:
... This
was bug #33558 and has been fixed in 4.4.1RC1.
Does that give 34551 any chance of being fixed? 33558 is just
an annoying notice, but 34551 is a real BC break in 4.4 that
wasn't documented and will likely continue to bite
On Mon, 2005-09-19 at 22:36 +0400, Antony Dovgal wrote:
1) They are only notices, you don't *have* to fix them as they can be safely
silenced.
It would be nice if they could be safely silenced, but the bug I
just filed about the BC break in 4.4 (#34551) was just marked bogus,
so it looks like
Aha! That was the inspiration I needed to get the right
combination of s. The following bit of code behaves
differently under 4.3 vs 4.4:
?php
function f($a) { return $a; }
$x = array('a','b','c');
foreach (array_keys($x) as $k) {
// I think the following line disconnects $y in 4.3
// but
(based on the = even the can't
really be used) before being set, the behavior would
have matched 4.3.
- Todd
On Thu, 2005-09-15 at 22:08 -0700, Todd Ruth wrote:
Aha! That was the inspiration I needed to get the right
combination of s. The following bit of code behaves
differently under 4.3 vs
for Todd Ruth to send me a very helpful and informative e-mail on
the matter (i.e. everything the same as the last added bugs), which
shall help me greatly in tracking it down (thanks again, Todd!).
Regards,
Colin.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
. The fact that php loses its mind
in these cases has left me with the impression that php is sort of a
second class language. Putting the reference bugs to rest are the
most important bug fixes I can imagine. (No, I don't think it will
be feasible for us to move to php 5 anytime soon.)
Thank you!
- Todd
Ahh... my favorite topic. I think I covered all the cases
our company has hit in the following message to this list:
http://marc.theaimsgroup.com/?l=php-devm=109631219107237w=2
I've never seen a response as to whether there is hope for fixes
of these problems. I ended up hacking at an already
On Tue, 2004-10-19 at 02:42, Christian Schneider wrote:
The only restrictions I see is that it makes the parameter optional as
well (something I don't consider a problem as it is probably desirable
in most cases anyway to be able to leave out an explicit null) and that
it only works if no
follows! That's
*** exactly what you want for the type hint that allows null
*** case.
***
- Todd
On Tue, 2004-10-19 at 10:29, Todd Ruth wrote:
On Tue, 2004-10-19 at 02:42, Christian Schneider wrote:
The only restrictions I see is that it makes the parameter optional as
well
of reproducability, I never filed a bug
report for the crashes and corruptions I experienced. Do
any of the experts out there know if the underlying problems
have been addressed?
Thanks!
Todd
On Thu, 2004-04-08 at 18:53, Todd Ruth wrote:
I'm not sure if it caused any of the issues either of you
Something doesn't quite seem right to me about a position
that has both of the following assertions:
1) goto should not be available
2) there's already an equivalent of goto available, so
goto is not needed (and it's just fine that people
use the equivalent)
If you really believe 1,
goto poorly is a
strong candidate for making a difficult to read loop. Perhaps
it would be better to read a goto in their code than have to
figure out why they have that odd loop construct...
- Todd
On Fri, 2004-07-30 at 11:48, Zeev Suraski wrote:
At 21:37 30/07/2004, Todd Ruth wrote:
Something
That would satisfy some of the requested feature, but try
calling ifsetor($my_array['bad key'], functionWithSideEffects()).
Marcus has repeatedly mentioned that the requested feature is
hard (bordering on impossible) to implement, but in the requested
feature (if I understand it (and it is what I
You can avoid the E_NOTICE using a reference, but it can have undesired
side effects. For example, if you pass $x[5] by reference (whether to
an internal function or a user defined function), $x[5] will be
created and set to NULL. To avoid this side-effect, don't use the
reference and instead
I have a feeling that PHP has a memory problem somewhere :/.
I'm not sure if it caused any of the issues either of you spoke of,
but I can report that PHP does have some pointer problems. I've
been putting off this email until I had written up something nicer,
but it's probably better to just
Thanks for the replies.
First, in response to Stefan...
[EMAIL PROTECTED]:~$ php -r '$a = 2; $b = $a; debug_zval_dump($a);'
long(2) refcount(3)
[EMAIL PROTECTED]:~$
I missed that one. Thanks! With that I'd at least be
able to implement ref_count in php.
And then in response to Adam...
).)
Better?
- Todd
On Wed, 2004-03-03 at 12:54, Andi Gutmans wrote:
At 09:25 PM 3/3/2004 +0100, Derick Rethans wrote:
On Wed, 3 Mar 2004, Todd Ruth wrote:
Finding those bugs when you have tens of thousands of lines of
php can be a real headache. That's why I'd very much like
performance. We also
agreed that the best course is to write to the php development
community for guidance.
So... any thoughts?
Thanks!
Todd Ruth
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
54 matches
Mail list logo
