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
JC>>> I am quite getting tired of having to maintain BC for *every* little
JC>>> stupid thing we ever did. I think it's time to start with a clean slate
JC>>> as it's all getting way to annoying to maintain (and know what subtle
JC>>> differences there are between PHP versions).
The subtle dif
> 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 en
cool is that?
G!
- Steph
- Original Message -
From: "Jani Taskinen" <[EMAIL PROTECTED]>
To: "Christian Schneider" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, October 04, 2005 11:43 PM
Subject: Re: [PHP-DEV] $ref =& $this;
> On Tue, 4 Oct 2005, Chris
On Tue, 4 Oct 2005, Christian Schneider wrote:
Two things to consider:
1) If the PHP maintainers are getting sick of BC then it might be better
to break BC than to lose maintainers.
Well, losing couple of trolls like me is not bad thing, is it? :)
But yes, if PHP can't evolve, this wil
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 cop
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
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 para
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 = $
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
>
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 this
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 ar
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
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 ballast)
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, onl
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 ballast).
If I have a newly deve
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 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 yo
On Tue, 4 Oct 2005, Gareth Ardron wrote:
> Of course, the key thing here would be making sure that you could run
> php4.x/5.x alongside a php6 install so that people can easily test things
> without risk of breaking existing apps still on the same server.
It's quite easy to set something like tha
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 would
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
wou
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
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 think
m: 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, 9:49:00
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 di
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
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 becau
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;
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.
--
.--
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?
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
de
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 NOT
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 wi
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'
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
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 peo
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 co
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.n
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;
publ
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
>
40 matches
Mail list logo
