Hi,
On Thu, 6 Oct 2005 12:26:30 +0300 (IDT), in php.internals
[EMAIL PROTECTED] (Stanislav Malyshev) wrote:
The subtle differences are mostly because many of the developers don't
care for the BC. This leads to a state when if you code runs on x.y.z
version of PHP, you can't really be sure it
You would be surprised. At the moment I see it as the best option still,
until other people see what mess we're getting in - but they won't.
A split is far from being the best option. There are too many users out
there to make it even a sane option. Or did you plan on getting rid of
those
On Mon, 3 Oct 2005, Dmitry Stogov wrote:
At second disallowing such assignments and passign $this by reference will
breake a lot of PHP4 code (Mamaba CMS).
In PHP4 passing $object by refernce and by value had completely different
semantic.
Yes I know. In PHP 4 the OO was totally crap, and
Hello Derick,
Tuesday, October 4, 2005, 9:49:00 AM, you wrote:
On Mon, 3 Oct 2005, Dmitry Stogov wrote:
At second disallowing such assignments and passign $this by reference will
breake a lot of PHP4 code (Mamaba CMS).
In PHP4 passing $object by refernce and by value had completely
disallow it.
see follow...
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 04, 2005 12:03 PM
To: Derick Rethans
Cc: Dmitry Stogov; 'PHP Developers Mailing List'
Subject: Re: [PHP-DEV] $ref = $this;
Hello Derick,
Tuesday, October 4, 2005
Derick Rethans wrote:
I am quite getting tired of having to maintain BC for *every* little
stupid thing we ever did. I think it's time to start with a clean slate
as it's all getting way to annoying to maintain (and know what subtle
differences there are between PHP versions).
How do you
Bart van Bragt wrote:
There are some whacky things in PHP4 and PHP5 that need to be fixed and
to fix that BC sometimes breaks. No problem with that. The problem is
that you're breaking BC again while almost no-one has switched to PHP5
yet because of the BC breaks between 4.x and 5.0. Breaking
Lukas Smith wrote:
I think that eZ is an example of a company that shows its willing to
take a risk in betting their money on PHP6 only, because they are
producing a product that will then simply be on a cleaner basis for
its customers. Other companies in much more controlled environments
Lukas Smith wrote:
I think that eZ is an example of a company that shows its willing to
take a risk in betting their money on PHP6 only, because they are
producing a product that will then simply be on a cleaner basis for its
customers. Other companies in much more controlled environments
On Tue, 4 Oct 2005, Bart van Bragt wrote:
Starting with a clean slate would cool for you (it would enable you to do new
and cool things) but it would either force us to switch to a more stable
language or keep two completely different codebases. I know what I would
choose.
But who says your
On Tue, 4 Oct 2005, Bart van Bragt wrote:
Lukas Smith wrote:
I think that eZ is an example of a company that shows its willing to take a
risk in betting their money on PHP6 only, because they are producing a
product that will then simply be on a cleaner basis for its customers. Other
On 03 October 2005 15:41, Robert Cummings wrote:
Amazing how fast the assumption has become that passing
object values in
PHP5 is identical to passing the object by reference. It is not the
same, there are subtle differences. Either way I'm not weighing in on
the $ref = $this issue, only
Bart van Bragt wrote:
Derick Rethans wrote:
But who says your code should run on the new version? You don't *have*
to upgrade per se. It merely allows newly developed projects to run on
a cleaner version of PHP, which would undoubtfully also be faster
(because we wouldn't have any BC
Lukas Smith wrote:
See my note above. Everybody knows that clean ups will cause BC breaks
and everybody knows that designing code that never breaks BC is a futile
attempt that simply takes to long to be of any use out in the real
world. We just have to communicate more clearly when we do break
On Tue, 2005-10-04 at 09:49 +0200, Derick Rethans wrote:
I am quite getting tired of having to maintain BC for *every* little
stupid thing we ever did. I think it's time to start with a clean slate
as it's all getting way to annoying to maintain (and know what subtle
differences there are
Bart van Bragt wrote:
The 'communicate more clearly' part is what this (IMO) all boils down
to. As I said, I understand that BC breaks are sometimes needed, no
problem with that. The problem lies in the fact that we now all of the
I made a suggestion in regards to this a few days ago on
Ford, Mike schrieb:
Yes, very true. I've mentioned before that I think PHP 5's object
thingummies should be referred to as handles (and I'm sure I actually saw
this usage in early versions of the PHP 5 or Zend Engine 2 proposals). Then,
it's much clearer that:
$obj2 = $obj1
gives
Oliver Grätz wrote:
Ford, Mike schrieb:
Yes, very true. I've mentioned before that I think PHP 5's object
thingummies should be referred to as handles (and I'm sure I
actually saw this usage in early versions of the PHP 5 or Zend
Engine 2 proposals). Then, it's much clearer that:
$obj2 =
Marcus Boerger schrieb:
No. And it is even worse. We start maintaining BC for things we always
agreed we do not support
This gave me a very silly idea (or not?):
Release a PHP 4.9 version or something like that!
And here's what it looks like: It is a complete PHP 5.1 in disguise plus
a
Hello Dmitry,
Tuesday, October 4, 2005, 11:16:36 AM, you wrote:
Marcus, Derick,
$var = $this is proper code, however changing $var after such assignment
right in this methid can cause mesh. Only this method will be affected. Look
into example:
Which straw are you now reaching for? The one
Lukas Smith wrote:
to keep customers. This half-assed attempt at maintain BC is what is
really causing major problems.
The problem would be that this new PHP would be a wild mix of all
different changes. While I wouldn't mind a shiny new PHP with
-references removed altogether which always
Hello Derick,
Monday, October 3, 2005, 3:09:22 PM, you wrote:
Hello,
Dmitry committed a fix earlier to ignore the in the statement above. I
think this is not a good thing to do as it's simply conceptually wrong.
The first thing is that ignoring syntax without issuing a warning is
Hmmm I agree about the reassigning of $this, but not the passing of
$this by ref.
Example:
Class A {
public $tableName = 'Forum';
public $childObject;
public function __construct() {
$this-childObject = new B($this);
}
}
Class B {
private $parent;
On Mon, 3 Oct 2005, Richard Mann wrote:
Hmmm I agree about the reassigning of $this, but not the passing of
$this by ref.
Why are you passing an object be reference? Never heard that in PHP 5
objects are always references?
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no
Hi,
At first $ref = $this; produced fatal error because of the bug (not by
design).
For example $ref-prop = $this; worked and works without errors.
So my patch shouldn't be reverted in any case.
At second disallowing such assignments and passign $this by reference will
breake a lot of PHP4 code
Hello Dmitry,
that IS NOT proper code and it wasn't in php 4 either, it was only a
workaround that is no longer needed. Had the php 4 design been correct in
the first place that wouldn't have been allowed in 4 either. Since BC is not
working out anyway i see absolutley no reason to encourage
On 10/3/05, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Dmitry,
that IS NOT proper code and it wasn't in php 4 either, it was only a
workaround that is no longer needed. Had the php 4 design been correct in
the first place that wouldn't have been allowed in 4 either. Since BC is not
(it is not possile to eleminaty all such checks at compile time).
Dmitry.
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, October 03, 2005 6:14 PM
To: Dmitry Stogov
Cc: 'Derick Rethans'; 'PHP Developers Mailing List'
Subject: Re: [PHP-DEV] $ref = $this;
Hello
Hey,
I was the original person that started disallowing assigning $this by
reference.
Question really boils down to, how is this different from the
reference fixes we did a couple of weeks ago, where due to too many
apps breaking (and a lot broke) we created a work-around for this
behavior
See my note regarding the fixes we did in the past 1-2 weeks
regarding references. It's a huge BC break, and quite frankly, it's
not the kind of thing that forces you not to write good code because
it's supported.
Andi
At 07:13 AM 10/3/2005, Marcus Boerger wrote:
Hello Dmitry,
that IS
Assigning to it will break this in the symbol table, or EG(This)?
If it's the latter then it is a problem (and it's the reason I didn't
support it to begin with).
Andi
At 07:05 AM 10/3/2005, Dmitry Stogov wrote:
Hi,
At first $ref = $this; produced fatal error because of the bug (not by
On Mon, 2005-10-03 at 09:49, Derick Rethans wrote:
On Mon, 3 Oct 2005, Richard Mann wrote:
Hmmm I agree about the reassigning of $this, but not the passing of
$this by ref.
Why are you passing an object be reference? Never heard that in PHP 5
objects are always references?
Amazing
On Mon, 2005-10-03 at 10:40, Robert Cummings wrote:
Either way I'm not weighing in on the $ref = $this issue
Actually, I think I will.
I think $ref = $this is perfectly legal and
I think $this = $ref or $this = $anything is perfectly illegal.
Cheers,
Rob.
--
Andi Gutmans wrote:
Assigning to it will break this in the symbol table, or EG(This)? If
it's the latter then it is a problem (and it's the reason I didn't
support it to begin with).
Given that:
class foo {
function bar() {
$this-a = 1;
$ref = $this;
$ref-b = 2;
Yep, I agree with this. We'll check but I'm pretty sure we're not
corrupting EG(This) (which in any case is an implementation detail
and too relevant to this discussion).
As in PHP, you can't change the $this pointer, I do think we should
have a message about this. I'd suggest an E_WARNING
On Tue, 13 Sep 2005, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
But there are many other cases
where a function legitimately takes a by-ref and doesn't necessarily
write to it or the write is a secondary action not required for the code
to work. Could we not catch this on the write
At 15:36 14/09/2005, Derick Rethans wrote:
On Tue, 13 Sep 2005, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
But there are many other cases
where a function legitimately takes a by-ref and doesn't necessarily
write to it or the write is a secondary action not required for the code
to
Zeev Suraski wrote:
At 15:36 14/09/2005, Derick Rethans wrote:
On Tue, 13 Sep 2005, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
But there are many other cases
where a function legitimately takes a by-ref and doesn't necessarily
write to it or the write is a secondary action not
At 15:54 14/09/2005, Edin Kadribasic wrote:
Zeev Suraski wrote:
At 15:36 14/09/2005, Derick Rethans wrote:
On Tue, 13 Sep 2005, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
But there are many other cases
where a function legitimately takes a by-ref and doesn't necessarily
write to
On Wed, 14 Sep 2005, Andreas Ahlenstorf wrote:
Am 14.09.2005 um 14:36 schrieb Derick Rethans:
Since we can detect a ref to a temp var at call time now, how about
making a local copy in the function and effectively treat it as a
by-value arg and also issue an E_NOTICE or an E_STRICT?
Am 14.09.2005 um 15:10 schrieb Derick Rethans:
Of course it does, you have a ) too much. Besides this, the following
I should drink more coffee...
script does not make a fatal error:
?php
$name = derick;
array_pop(explode('.', $name));
?
Fatal error: Only variables can be passed by
Am 14.09.2005 um 15:40 schrieb Derick Rethans:
?php
$filename = sprintf('%s.%s', md5(uniqid(rand(), true)), array_pop
(explode('.', $name)));
echo $filename;
D'oh - I see it. My ISP changed the PHP version once again. It's now
PHP 5.0.5. I'm very very sorry for the confusion.
A.
--
Hello Rasmus,
my solution was (and i proposed a patch for it here) that we have a way
to allow function signatures that pass variables as const just like c++
allows. This i did because first it is faster and second it applies to
most pass by ref signatures. Or in other words we could get rid of
Zeev Suraski wrote:
At 15:36 14/09/2005, Derick Rethans wrote:
On Tue, 13 Sep 2005, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
But there are many other cases
where a function legitimately takes a by-ref and doesn't necessarily
write to it or the write is a secondary action not
On 9/14/05, Zeev Suraski [EMAIL PROTECTED] wrote:
I think it's probably equally big, but it's besides the point. I'm trying
to understand what we can do (in 5.0.6 or whatever) that will really solve
the problem. The 4.4 approach at this point doesn't appear to be any
better since regardless
Just got back from Sri Lanka and am catching up on email. But in
general I don't agree with your statement that things that are quiet in
5.0.4 must be quiet in 5.0.5. Quietly corrupting memory doesn't really
work. Sometimes we need to break things slightly to fix things. My
message was more
On 9/13/05, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
Just got back from Sri Lanka and am catching up on email. But in
general I don't agree with your statement that things that are quiet in
5.0.4 must be quiet in 5.0.5. Quietly corrupting memory doesn't really
work. Sometimes we need to
Pierre Joye wrote:
As it is too late now anyway, regain BC makes little sense.
I don't agree. This is one of the main things stopping people from
migrating to PHP5 right now. If we can remove a bit of the migration
pain with some of clever temp var handling, I think it is worthwhile.
-Rasmus
Hi,
Rasmus Lerdorf mailto:[EMAIL PROTECTED] wrote on Tuesday, September 13,
2005 3:08 PM:
As it is too late now anyway, regain BC makes little sense.
I don't agree. This is one of the main things stopping people from
migrating to PHP5 right now. If we can remove a bit of the migration
Zeev Suraski wrote:
But there are many other cases
where a function legitimately takes a by-ref and doesn't necessarily
write to it or the write is a secondary action not required for the code
to work. Could we not catch this on the write instead of on the call?
The problem is that
At 18:07 12/09/2005, Derick Rethans wrote:
On Mon, 12 Sep 2005, Zeev Suraski wrote:
I don't really agree that it's out of whack, since you are passing a
piece of
data by reference, which is an undefined behavior. I agree that it
would have
been nice if we could allow for this and only
At 21:22 13/09/2005, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
But there are many other cases
where a function legitimately takes a by-ref and doesn't necessarily
write to it or the write is a secondary action not required for the code
to work. Could we not catch this on the write instead
At 10:57 12/09/2005, Rasmus Lerdorf wrote:
Guys, could we take a look at making the ref to temp var fix a bit
narrower? Currently we try to catch it at call-time. This means that
something like:
current(explode(' ','a b'))
as per bug #34468 doesn't work. Now, I think there is a secondary
On Mon, 12 Sep 2005, Zeev Suraski wrote:
I don't really agree that it's out of whack, since you are passing a piece of
data by reference, which is an undefined behavior. I agree that it would have
been nice if we could allow for this and only complain if the data is written
to in the
Hi Rasmus,
You start a new thread for my question, maybe you will get more
answers or at least better ones.
If it is a reference or not, I do not care, it should not act
differently. Understand that a quiet code in 5.0.4 must be quiet in
5.0.5.
If we add notices in 5.1.0 and then make them
55 matches
Mail list logo
