# Unexpected "silent" type-cast with initialized but un-set members

- Thread: https://externals.io/message/21877
- Original archive: https://news-web.php.net/php.internals/21877
- Started by Morten Fangel on 2006-02-16T11:32:48+00:00
- Messages: 5
- 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

---

## #21877 — Morten Fangel — 2006-02-16T11:32:48+00:00

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

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

---

## #21878 — Antony Dovgal — 2006-02-16T11:39:39+00:00

URL: https://externals.io/message/21877#21878 · In reply to: #21877

> 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

---

## #21879 — Morten Fangel — 2006-02-16T11:55:36+00:00

URL: https://externals.io/message/21877#21879 · In reply to: #21878

> <?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

---

## #21881 — Jochem Maas — 2006-02-16T12:45:19+00:00

URL: https://externals.io/message/21877#21881 · In reply to: #21879

Morten Fangel wrote:
> 
> 
> > […]
> 
> 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)

<!--

unset($a); $a->i = 1; 				// this is not a problem
$b = 1; $c = 2; $d = array_merge($b, $c);	// but this is bad programming?

-->

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

---

## #21882 — Morten Fangel — 2006-02-16T12:57:49+00:00

URL: https://externals.io/message/21877#21882 · In reply to: #21881

> 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)
>
> <!--
>
> unset($a); $a->i = 1; 				// this is not a problem
> $b = 1; $c = 2; $d = array_merge($b, $c);	// but this is bad programming?
>
> -->
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