Hi,
Look at the following example:
<?php
class Foo {
public $bar;
function __construct() {
$this->bar->baz = 'blah';
}
}
$foo = new Foo();
print_r($foo);
?>
It results in:
Foo Object
(
[bar] => stdClass Object
(
[baz] => blah
)
)
Foo->bar is never declared as anything but "public" and is therefor
"type-less" (is there a proper term for this?).
As soon as I try to assign Foo->bar->baz, then Foo->bar is cast to an
stdObject and the baz property is set.
This is pretty much what you would expect, but IMHO this should generate an
E_NOTICE because you are using a non-object as an object..
Is this just my opinion?
Morten Fangel // fangel
Hi,
Look at the following example:
<?php
class Foo {
public $bar;
function __construct() {
$this->bar->baz = 'blah';
}
}
$foo = new Foo();
print_r($foo);
?>It results in:
Foo Object
(
[bar] => stdClass Object
(
[baz] => blah
)
)
<?php
$a->bar = 1;
var_dump($a);
?>
This code is much simpler, huh?
--
Wbr,
Antony Dovgal
<?php
$a->bar = 1;
var_dump($a);
?>
This code is much simpler, huh?
Yeah, I must have been blinded by the lights. It merely resembles
$foo['bar'] = 'baz';
Where $foo is cast as an array without the need to do $foo = array(); first.
So I guess there is no need for a notice when you apply the same "pattern" to
an object.
Wow - what a great debut on the internals list, huh? ;)
Morten
Morten Fangel wrote:
<?php
$a->bar = 1;
var_dump($a);
?>
This code is much simpler, huh?Yeah, I must have been blinded by the lights. It merely resembles
$foo['bar'] = 'baz';
Where $foo is cast as an array without the need to do $foo = array(); first.So I guess there is no need for a notice when you apply the same "pattern" to
an object.
if that is the logic being applied in the engine then one might to wonder why a
function such as array_merge() was changed to emit a warning when any of
it's arguments are not arrays (whereas sometime in the past it used to swallow
[and I assume 'autocast'] whatever it was given without a hiccup).
I have been told that such warnings as array_merge() now emits are for my own
good (in not so many words I was told it was "to protect me from my stupid self"),
if it's good for me when I use array_merge() why not when an object is created
implicitly (as in the example above)? actually my preference would be to drop the warning
in array_merge() in this case (it seems like a more php way of doing things, imo)
I'm very interested to learn what people think about this kind of thing in general -
and obviously if someone knows of material that explains the reasoning behind the
percieved inconsistency/problem I'd be very grateful.
tar,
jochem
if that is the logic being applied in the engine then one might to wonder
why a function such asarray_merge()was changed to emit a warning when any
of it's arguments are not arrays (whereas sometime in the past it used to
swallow [and I assume 'autocast'] whatever it was given without a hiccup).I have been told that such warnings as
<!-- unset($a); $a->i = 1; // this is not a problem $b = 1; $c = 2; $d = array_merge($b, $c); // but this is bad programming? -->array_merge()now emits are for my
own good (in not so many words I was told it was "to protect me from my
stupid self"), if it's good for me when I usearray_merge()why not when an
object is created implicitly (as in the example above)? actually my
preference would be to drop the warning inarray_merge()in this case (it
seems like a more php way of doing things, imo)
This was my initial thought when I saw the behaviour: "wow - this just wants
you to do some lousy programmering" and therefor thought that it needed a
E_NOTICE.. (which I still do, but now I understand why it currently don't do
so)
If some functions throws notices when they have to "autocast", why doesn't php
always do this (throws notices)? Or maybe it should just throw E_STRICT and
let the perfectionists remove those issues if they want to do so...
I'm very interested to learn what people think about this kind of thing in
general - and obviously if someone knows of material that explains the
reasoning behind the percieved inconsistency/problem I'd be very grateful.tar,
jochem
Regards
Morten