# $ref =& $this;

- Thread: https://externals.io/message/19336
- Original archive: https://news-web.php.net/php.internals/19336
- Started by Derick Rethans on 2005-10-03T13:09:22+00:00
- Messages: 32
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/19336.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #19336 — Derick Rethans — 2005-10-03T13:09:22+00:00

URL: https://externals.io/message/19336#19336

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 
dubious because people might think it does actually work, and secondly 
because I think that the code above is wrong anyway - somewhat in the 
same way that "$this = new foo();" is wrong.

There is never any need to assign $this by reference, nor to pass it by 
reference to a function as it's an object anyway, making the references 
pointless - I would even go as far as disallowing passing $this by 
references to a function - where the reference has to be ignored again, 
otherwise it allows you to chantge $this to a different object with:

class Foo {
	function byRef(&$f) {
		$f = new Bar();
	}

	function modifyThis() {
		$this->byRef($this);
	}
}

I think we should prevent people from writing syntax like this, as it is 
not obvious what is going to happen. This means that we should revert 
Dmitry's patch.

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #19337 — Marcus Boerger — 2005-10-03T13:21:38+00:00

URL: https://externals.io/message/19336#19337 · In reply to: #19336

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 
> dubious because people might think it does actually work, and secondly 
> because I think that the code above is wrong anyway - somewhat in the 
> same way that "$this = new foo();" is wrong.

> There is never any need to assign $this by reference, nor to pass it by 
> reference to a function as it's an object anyway, making the references 
> pointless - I would even go as far as disallowing passing $this by 
> references to a function - where the reference has to be ignored again, 
> otherwise it allows you to chantge $this to a different object with:

> class Foo {
>         function byRef(&$f) {
>                 $f = new Bar();
>         }

>         function modifyThis() {
>                 $this->byRef($this);
>         }
> }

> I think we should prevent people from writing syntax like this, as it is 
> not obvious what is going to happen. This means that we should revert 
> Dmitry's patch.

Same here.


Best regards,
 Marcus

---

## #19338 — Pierre — 2005-10-03T13:30:29+00:00

URL: https://externals.io/message/19336#19338 · In reply to: #19336

On Mon, 3 Oct 2005 15:09:22 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:

> I think we should prevent people from writing syntax like this, as it
> is not obvious what is going to happen. 

I agree too.

The question is only about how to prevent users to do that without
breaking "everything" out there.

I would like to go with a notice for the next stable release (both
5.0.x and 5.1.0) and see when we can make it as a fatal error,
something like 5.2 or so. HEAD can keep the error as it was.


--Pierre

---

## #19339 — Christian Schneider — 2005-10-03T13:39:00+00:00

URL: https://externals.io/message/19336#19339 · In reply to: #19336

Derick Rethans wrote:
> pointless - I would even go as far as disallowing passing $this by 
> references to a function - where the reference has to be ignored again, 

This would be needed to have something like

function setfoo(&$obj)
{
	$obj->foo = 42;
}

[...]
$other->setfoo($this);

in a way which also works for PHP4.

a) I know that you now are going to bash me for mentioning PHP4
b) No, I don't think this is very common or elegant

But disallowing it might break existing code, no?

- Chris

---

## #19341 — Richard Mann — 2005-10-03T13:39:39+00:00

URL: https://externals.io/message/19336#19341 · In reply to: #19337

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;

    public function __construct(&$parent) {

        $this->parent = &$parent;

    }

    public function get_stuff() {

        // Generate SQL useing the parents global table name settings
etc....

    }

}




On Mon, 3 Oct 2005 15:21:38 +0200
Marcus Boerger <helly@php.net> wrote:

> Hello Derick,
> 
> Monday, October 3, 2005, 3:09:22 PM, you wrote:
> 
> > […]
> 
> > […]
> 
> > […]
> 
> > […]
> 
> > […]
> 
> > […]
> 
> Same here.
> 
> 
> Best regards,
>  Marcus
> 
> -- 
> 
> 


====================================================================
Richard Mann (Programmer)
-=
Skynet Internet Services

a: 8 Premier Court
    Boarden Close
    Moulton Park
    Northampton
    NN3 6LF
-=
t: 0845 1 20 65 90 (General)
t: 0845 1 24 44 00 (Sales)
f: 0845 1 20 65 91
w: http://www.sky.net.uk/
-=
D I S C L A I M E R
Statements and opinions expressed in this e-mail may not represent those
of the company.

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender immediately and delete
the material from any computer.  
====================================================================

---

## #19340 — Marcus Boerger — 2005-10-03T13:40:41+00:00

URL: https://externals.io/message/19336#19340 · In reply to: #19339

Hello Christian,

  php 4 code is wrong in this and we don't want to support the errors
forever.

marcus

Monday, October 3, 2005, 3:39:00 PM, you wrote:

> Derick Rethans wrote:
> > […]

> This would be needed to have something like

> function setfoo(&$obj)
> {
>         $obj->foo = 42;
> }

> [...]
> $other->setfoo($this);

> in a way which also works for PHP4.

> a) I know that you now are going to bash me for mentioning PHP4
> b) No, I don't think this is very common or elegant

> But disallowing it might break existing code, no?

> - Chris




Best regards,
 Marcus

---

## #19342 — Derick Rethans — 2005-10-03T13:49:49+00:00

URL: https://externals.io/message/19336#19342 · In reply to: #19341

> 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 | http://xdebug.org

---

## #19343 — Dmitry Stogov — 2005-10-03T14:05:56+00:00

URL: https://externals.io/message/19336#19343 · In reply to: #19336

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 (Mamaba CMS).
In PHP4 passing $object by refernce and by value had completely different
semantic.

I don't see any reason to disallow 100% proper code (like the the
following).

class Child {
  function Child($parent) {
    $parent->children[] =& $this;
  }
}

Of course using "=& $this" user can breake $this value, but other languages
(C++) allows this too.
I don't think we should be paranoiacs.

Thanks. Dmitry.


> -----Original Message-----
> From: Derick Rethans [mailto:derick@php.net] 
> Sent: Monday, October 03, 2005 5:09 PM
> To: PHP Developers Mailing List
> Subject: [PHP-DEV] $ref =& $this;
> 
> 
> 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 
> dubious because people might think it does actually work, and 
> secondly 
> because I think that the code above is wrong anyway - somewhat in the 
> same way that "$this = new foo();" is wrong.
> 
> There is never any need to assign $this by reference, nor to 
> pass it by 
> reference to a function as it's an object anyway, making the 
> references 
> pointless - I would even go as far as disallowing passing $this by 
> references to a function - where the reference has to be 
> ignored again, 
> otherwise it allows you to chantge $this to a different object with:
> 
> class Foo {
> 	function byRef(&$f) {
> 		$f = new Bar();
> 	}
> 
> 	function modifyThis() {
> 		$this->byRef($this);
> 	}
> }
> 
> I think we should prevent people from writing syntax like 
> this, as it is 
> not obvious what is going to happen. This means that we should revert 
> Dmitry's patch.
> 
> regards,
> Derick
> 
> -- 
> Derick Rethans
> http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #19344 — Marcus Boerger — 2005-10-03T14:13:44+00:00

URL: https://externals.io/message/19336#19344 · In reply to: #19343

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 people to
continue to missuse php.

marcus

Monday, October 3, 2005, 4:05:56 PM, you wrote:

> 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 (Mamaba CMS).
> In PHP4 passing $object by refernce and by value had completely different
> semantic.

> I don't see any reason to disallow 100% proper code (like the the
> following).

> class Child {
>   function Child($parent) {
>     $parent->children[] =& $this;
>   }
> }

> Of course using "=& $this" user can breake $this value, but other languages
> (C++) allows this too.
> I don't think we should be paranoiacs.

> Thanks. Dmitry.


> > […]




Best regards,
 Marcus

---

## #19345 — Jason Sweat — 2005-10-03T14:21:08+00:00

URL: https://externals.io/message/19336#19345 · In reply to: #19344

> 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 people to
> continue to missuse php.
>
> marcus

The central issue I see in this regards is that up until this point,
people had the option of writing reasonably complex OO code which
worked on both PHP4 and PHP5.  With the advent of disallowing =&
$this;  you are explicitly forcing people to create PHP5 branches of
their code.

I believe this will also act as a further deterant for hosts to
migrate to PHP5, as there will be an even greater number of off the
shelf PHP applications which are no longer compatable with PHP5.

Regards,
Jason
http://blog.casey-sweat.us/

---

## #19347 — Christian Schneider — 2005-10-03T14:29:19+00:00

URL: https://externals.io/message/19336#19347 · In reply to: #19340

Marcus Boerger wrote:
>   php 4 code is wrong in this and we don't want to support the errors
> forever.

Programming is like sex: One mistake and you have to maintain it for the 
rest of your life (-:C

Sometimes I wish I would have insisted more in Nov. 1999 when I brought 
up the reference vs. cloning issue for PHP4 beta. Oh well...

Anyway, if you break compatibility with PHP4 you risk that _fewer_ 
people migrate to it, not more. Lots of PHP4 code is out there and easy 
migration is key. That's why I'd advocate an `E_STRICT` plus disallow it 
in PHP7 (or PHP8 ;-)).

- Chris

---

## #19348 — Andi Gutmans — 2005-10-03T14:29:30+00:00

URL: https://externals.io/message/19336#19348 · In reply to: #19336

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 with a warning.
I think this case is pretty much identical, so we should probably 
treat it as such and escalate to error in 6.0.

And

At 06:09 AM 10/3/2005, Derick Rethans 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
>dubious because people might think it does actually work, and secondly
>because I think that the code above is wrong anyway - somewhat in the
>same way that "$this = new foo();" is wrong.
>
>There is never any need to assign $this by reference, nor to pass it by
>reference to a function as it's an object anyway, making the references
>pointless - I would even go as far as disallowing passing $this by
>references to a function - where the reference has to be ignored again,
>otherwise it allows you to chantge $this to a different object with:
>
>class Foo {
>         function byRef(&$f) {
>                 $f = new Bar();
>         }
>
>         function modifyThis() {
>                 $this->byRef($this);
>         }
>}
>
>I think we should prevent people from writing syntax like this, as it is
>not obvious what is going to happen. This means that we should revert
>Dmitry's patch.
>
>regards,
>Derick
>
>--
>Derick Rethans
>http://derickrethans.nl | http://ez.no | http://xdebug.org
>
>--
>
>


Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/

---

## #19349 — Andi Gutmans — 2005-10-03T14:31:37+00:00

URL: https://externals.io/message/19336#19349 · In reply to: #19344

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 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 people to
>continue to missuse php.
>
>marcus
>
>Monday, October 3, 2005, 4:05:56 PM, you wrote:
>
> > […]
>
> > […]
>
> > […]
>
> > […]
>
> > […]
>
> > […]
>
> > […]
>
> > […]
>
>
> > […]
>
>
>
>
>Best regards,
>  Marcus
>
>--
>
>


Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/

---

## #19350 — Andi Gutmans — 2005-10-03T14:32:27+00:00

URL: https://externals.io/message/19336#19350 · In reply to: #19343

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
>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 (Mamaba CMS).
>In PHP4 passing $object by refernce and by value had completely different
>semantic.
>
>I don't see any reason to disallow 100% proper code (like the the
>following).
>
>class Child {
>   function Child($parent) {
>     $parent->children[] =& $this;
>   }
>}
>
>Of course using "=& $this" user can breake $this value, but other languages
>(C++) allows this too.
>I don't think we should be paranoiacs.
>
>Thanks. Dmitry.
>
>
> > […]
>
>--
>
>


Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/

---

## #19351 — Marcus Boerger — 2005-10-03T14:35:47+00:00

URL: https://externals.io/message/19336#19351 · In reply to: #19347

Hello Christian,

Monday, October 3, 2005, 4:29:19 PM, you wrote:

> Marcus Boerger wrote:
> > […]

> Programming is like sex: One mistake and you have to maintain it for the 
> rest of your life (-:C

> Sometimes I wish I would have insisted more in Nov. 1999 when I brought 
> up the reference vs. cloning issue for PHP4 beta. Oh well...

> Anyway, if you break compatibility with PHP4 you risk that _fewer_ 
> people migrate to it, not more. Lots of PHP4 code is out there and easy 
> migration is key. That's why I'd advocate an `E_STRICT` plus disallow it 
> in PHP7 (or PHP8 ;-)).

 `E_STRICT` in 5.0, 51 is the least thing we need to do and probably we should
simply stop supporting 4.4 otherwise we never have our user base upgrade.

Best regards,
 Marcus

---

## #19352 — Robert Cummings — 2005-10-03T14:40:33+00:00

URL: https://externals.io/message/19336#19352 · In reply to: #19342

> 
> 
> > […]
> 
> Why are you passing an object be reference? Never heard that in PHP 5 
> objects are always references?

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 that $obj = $someObj is NOT the same as
$obj = &$someObj.

<?php

class FooA{}
class FooB{}

$a = new FooA();
$b = new FooB();

$blah1 = &$a;
$blah2 = &$blah1;
$blah1 = $b;
print_r( $blah2 );

unset( $a, $b, $blah1, $blah2 );

$a = new FooA();
$b = new FooB();

$blah1 = $a;
$blah2 = $blah1;
$blah1 = $b;
print_r( $blah2 );

?>

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

---

## #19353 — Robert Cummings — 2005-10-03T14:46:15+00:00

URL: https://externals.io/message/19336#19353 · In reply to: #19352

> 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.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

---

## #19355 — Rasmus Lerdorf — 2005-10-03T15:11:30+00:00

URL: https://externals.io/message/19336#19355 · In reply to: #19350

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;
      $ref = null;
    }
  }
  $x = new foo;
  $x->bar();
  echo $x->a, $x->b;

Outputs 12 and doesn't appear to cause any major badness internally, I
don't really see any reason to disallow it.  If an `E_STRICT` could be
raised without affecting performance too much that would be good since
it is a useless assignment.  Given the lack of badness on the php5 side
and the high level of goodness for php4 portability, I say leave it as
it is now.

-Rasmus

---

## #19356 — Andi Gutmans — 2005-10-03T16:07:51+00:00

URL: https://externals.io/message/19336#19356 · In reply to: #19355

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` because it's for 
the same reason as over writing $this that you'd want to take a 
reference, you shouldn't really do it. We can also mention in the 
warning that this support will be deprecated in future versions...

Andi

At 08:11 AM 10/3/2005, Rasmus Lerdorf wrote:
>Andi Gutmans wrote:
> > […]
>
>Given that:
>
>   class foo {
>     function bar() {
>       $this->a = 1;
>       $ref = &$this;
>       $ref->b = 2;
>       $ref = null;
>     }
>   }
>   $x = new foo;
>   $x->bar();
>   echo $x->a, $x->b;
>
>Outputs 12 and doesn't appear to cause any major badness internally, I
>don't really see any reason to disallow it.  If an `E_STRICT` could be
>raised without affecting performance too much that would be good since
>it is a useless assignment.  Given the lack of badness on the php5 side
>and the high level of goodness for php4 portability, I say leave it as
>it is now.
>
>-Rasmus


Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/

---

## #19363 — Derick Rethans — 2005-10-04T07:41:39+00:00

URL: https://externals.io/message/19336#19363 · In reply to: #19339

> a) I know that you now are going to bash me for mentioning PHP4
> b) No, I don't think this is very common or elegant
> 
> But disallowing it might break existing code, no?

Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion 
anyway.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #19365 — Marcus Boerger — 2005-10-04T07:53:31+00:00

URL: https://externals.io/message/19336#19365 · In reply to: #19363

Hello Derick,

Tuesday, October 4, 2005, 9:41:39 AM, you wrote:

> 

> > […]

> Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion 
> anyway.

I can only emphasize this.


Best regards,
 Marcus

---

## #19366 — Christian Schneider — 2005-10-04T08:02:38+00:00

URL: https://externals.io/message/19336#19366 · In reply to: #19363

Derick Rethans wrote:
> Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion 
> anyway.

No, it's not. What are you talking about? We've been happily using PHP4 
with OOP for years. That's basic OO like encapsulating data and 
inheritance to extend behaviour. Nothing of that "fancy" exception/PPP 
type of OO, just the OO which really helps us ;-)

And the code _does_ work with PHP5.

Please stop the FUD,
- Chris

---

## #19370 — Christian Schneider — 2005-10-04T08:14:05+00:00

URL: https://externals.io/message/19336#19370 · In reply to: #19351

Marcus Boerger wrote:
> `E_STRICT` in 5.0, 51 is the least thing we need to do and probably we should
> simply stop supporting 4.4 otherwise we never have our user base upgrade.

While we would love to upgrade to PHP5 there is one killer for us so far:
None of the open caches (Zend cache is not an option for us) work 
reliably. They a) start crashing or behaving weird after a while and b) 
don't work on 64bit systems (yes, some of our non-PHP code would profit 
from 64bit) when we tried recently.

So switching from PHP4/mmcache to PHP5 would mean we have to buy more 
machines and we'd still get higher latency which is no good.

George: APC did quite well but started doing weird things (weird 
warnings, not crashing though) after a while. If you have any hints for 
me on how to provide you with information necessary to fix the problem, 
I'd be glad. I will install 3.0.8 on my development machine again and 
try to describe what happens.

Please accept that there are and will be real people with real problems 
with PHP5 out there for a while,
- Chris

---

## #19372 — Michael Wallner — 2005-10-04T08:29:54+00:00

URL: https://externals.io/message/19336#19372 · In reply to: #19365

Hi Marcus Boerger, you wrote:
> Hello Derick,
> 
> 
> > […]
> 
> 
> I can only emphasize this.

Frankly, this is not the PHP users fault at all.

If PHP5 would have been the PHP5 many had expected and
had broken lots of more things and if you (not tied to
one person) would have educated users about that, there
wouldn't be such "illusions" at all.

Regards,
-- 
Michael - < mike(@)php.net

---

## #19374 — Christian Schneider — 2005-10-04T08:56:00+00:00

URL: https://externals.io/message/19336#19374

Jani Taskinen wrote:
>     Yes, but OO in PHP 4 is illusion.

Ok, I see, I replied to a troll. Silly of me. Won't happen again after 
this one, I promise.

>     Nobody's bashing you for using PHP. Just for using PHP 4. :)

Are you reading my posts? Oh no, I forgot, you're just trolling.

Over and out,
- Chris

---

Next page: https://externals.io/message/19336.md?page=2