> 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 toda
> 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 th
> ...
> 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 expr
On Sat, 2015-03-14 at 00:22 +0100, Bob Weinand wrote:
> > Am 14.03.2015 um 00:14 schrieb Zeev Suraski :
> >
> >> -Original Message-
> >> From: Bob Weinand [mailto:bobw...@hotmail.com]
> >> Sent: Saturday, March 14, 2015 1:07 AM
> >> To: PHP Internals List
> >> Cc: Zeev Suraski; guilhermebl
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
On 8 Jul 2014, at 15:48, Derick Rethans 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 and ZF is
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 lea
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
[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 b
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
$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 objec
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';
> > fore
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
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:
I'm not sure where (if anywhere) that technique is documented
or even if it should be documented,
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-internals&m=103625548402350&w=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 P
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
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 def
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 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
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 affec
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 s
back to my 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
==float for the suggestion box.
- Todd
On Fri, 2008-04-11 at 20:29 -0700, Rasmus Lerdorf wrote:
> 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
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 "\n";
var_dump($max);
var_dum
> > 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 relea
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, Andre
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,
ay 24 July 2006 17:52, Rishad Omar wrote:
> > getArray($p = array());
>
> Here you are relying on undefined behavior. It is not defined wether $p =
> array() or the function call getarray($p) should be executed first so the
> order might always change.
>
> You
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.
see why it has to be a fatal error. If there's an instanceof
> relationship we can keep $this. If not, we should not pass $this
> (which I believe we already do in PHP 5), in which case the author
> would have to pass $this if he wants to change public properties.
>
> Andi
>
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()
> >>
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.
Y
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 t
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 myse
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 peop
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 lik
s",
are you saying that you were aware of a BC break beyond
memory corruption and didn't mention it?
Thanks,
Todd
On Fri, 2005-09-16 at 08:21 -0400, Derick Rethans wrote:
> On Thu, 15 Sep 2005, Todd Ruth wrote:
>
> > Aha! That was the inspiration I needed to get the right
>
unset (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 "&
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:
My guess would be that in 4.3 the engine tries to do the
reference even though it may be dangerous. That would
"disconnect" $y from the previous $z[].
n our code.
Thanks,
Todd
> ... I may not have provided any code, but this problem description was
> enough 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 tra
e soon.)
Thank you!
- Todd Ruth
On Mon, 2005-05-30 at 16:44 +0200, Derick Rethans wrote:
> On Mon, 30 May 2005, Christian Schneider wrote:
>
> > Derick Rethans wrote:
> > > >If you decide not to fix the 4.x branch then we'd minimally need an
> > > >easily
>
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-dev&m=109631219107237&w=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
Here is one reason: $x = @$y[3];
What should isset($x) return if $y doesn't have an
index 3?
If php had distinct concepts of "undefined" (perhaps
this would be a software level undefined value) and
"null" (perhaps this would be a built-in user level
undefined value), things would work very differ
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 (something I don't consider a problem as it is probabl
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 n
ck 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
structure. Someone who would use "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 Sur
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", shoul
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 w
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
The thing I like about the suggestion over implementing
the function in script is the ability to skip the call to
a function that provides the default. In the following
example, slowFunc() simulates a slow function using a sleep,
but you can imagine any function call with a performance
hit. The s
> > 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
riate).)
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 he
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...
east felt it was worthwhile.
(Who knows; maybe uninitialized values are contributing to
bugs in php...) As it was, it was a throw-away effort. My
boss suggested keeping a separate table instead of adding
to the zval struct and just ignoring the cases in which
an unitialized zval is looked for in the table. We agreed
that isn't as clean and has worse 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
58 matches
Mail list logo
