I am using phpunit on PHP 7.0.n. The last PHP version bump breaks this https://github.com/sebastianbergmann/phpunit-mock-objects/issues/371

If we could not bump minimum PHP versions in minors that would be great. ❤️

final class Foo extends ArrayIterator
{
}

(new \Doctrine\Instantiator\Instantiator()->instantiate(Foo::class);

PHP Fatal error:  Uncaught Exception: unserialize(): Error at offset 13 of 14 bytes in /Users/cmcnulty/Documents/Code/phpspec/vendor/doctrine/instantiator/src/Doctrine/Instantiator/Exception/UnexpectedValueException.php:76

Reproduced on 1.0.5 and 1.1.0 and, not had a chance to debug. Was reported to PhpSpec as https://github.com/phpspec/phpspec/issues/1124

No idea...!

It looks like HHVM dies when trying to clone a DateTime that has been instantiated with instantiator.

davem@wes:instantiator:failing-hhvm-test$ hhvm --version
HipHop VM 3.3.0 (rel)
Compiler: tags/HHVM-3.3.0-0-g0a3cfb87b8a353fc7e1d15374f4adc413e37aba9
Repo schema: 9a391d9a03e15fccba1cde6d35c05b7cdd380238
Extension API: 20140829
davem@wes:instantiator:failing-hhvm-test$ hhvm vendor/bin/phpunit
PHPUnit 4.3.1 by Sebastian Bergmann.

Configuration read from /home/davem/src/instantiator/phpunit.xml.dist

..........
Fatal error: A null object pointer was used. in /home/davem/src/instantiator/src/Doctrine/Instantiator/Instantiator.php on line 73

Though it's happy to do so with a DateTime that has been constructed normally:

davem@wes:instantiator:failing-hhvm-test$ cat t.php
<?php

$a = new DateTime();
$b = clone $a;

echo $b->format('r');
davem@wes:instantiator:failing-hhvm-test$ hhvm t.php
Mon, 06 Oct 2014 23:28:45 +0100%

the changes on 1.1.0, such as

syntax error, unexpected ':', expecting ';' or '{' 

at vendor/doctrine/instantiator/src/Doctrine/Instantiator/Instantiator.php:95

broke phpunit on PHP 5.4 ~ PHP 5.6

Here's the dependency tree:

phpunit/phpunit 4.8.24 The PHP Unit Testing framework.
├──ext-dom *
├──ext-json *
├──ext-pcre *
├──ext-reflection *
├──ext-spl *
├──php >=5.3.3
├──phpspec/prophecy ^1.3.1
│  ├──doctrine/instantiator ^1.0.2
│  │  └──php >=5.3,<8.0-DEV

I wonder to know how to force composer to install the old release of doctrine/instantiator ^1.0.2.

Hey,

Currently i'm unable to test (via instanciator) File object or any object that extends this class because Instanciator failed :(

Given error :

Could not produce an instance of "Domain\Mail\Attachment" via un-serialization, since an error was triggered in file "vendor/doctrine/instantiator/src/Doctrine/Instantiator/Instantiator.php" at line "184" (Doctrine\Instantiator\Exception\UnexpectedValueException)

Have you an idea, how deal with object containing a Resource ?

I don't know how this might be solved, but some builtin classes are not cloneable:

PHP 5.6.0 (cli) (built: Oct  4 2014 20:41:37)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
    with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

<?php

require "vendor/autoload.php";

$instantiator = new \Doctrine\Instantiator\Instantiator();
$instance = $instantiator->instantiate('MongoCollection');

PHP Fatal error:  Trying to clone an uncloneable object of class MongoCollection in /Users/davem/src/instantiator/src/Doctrine/Instantiator/Instantiator.php on line 74
PHP Stack trace:
PHP   1. {main}() /Users/davem/src/instantiator/test.php:0
PHP   2. Doctrine\Instantiator\Instantiator->instantiate() /Users/davem/src/instantiator/test.php:6

I'm not aware of any way in which to tell if something isn't cloneable...

For some reason in PHP > 5.6 you're checking a class isn't final and internal, instead you should be checking it's not final w/ internal ancestors (as in the case below for PHP > 5.4)

This is linked to https://github.com/phpspec/phpspec/issues/704

Related to https://github.com/doctrine/instantiator/issues/39

This is my attempt to resolve a long on-going issue on the phpspec repository, taking inspiration on the SF VarExporter component.

I do not see any other missing testcases, however feel free to let me know if you think about some, I will happily add them.

/cc @ciaranmcnulty @Ocramius @mikeSimonson

$ composer req doctrineorm Using version ^1.0 for symfony/orm-pack ./composer.json has been updated Loading composer repositories with package information Updating dependencies (including require-dev) Your requirements could not be resolved to an installable set of packages.

Problem 1 - doctrine/instantiator 1.0.1 requires php ~5.3 -> your PHP version (7.1.8) does not satisfy that requirement.

Hello, I wasn't sure if I had to post this here or on doctrine/orm : doctrine/orm 2.5.x-dev requires doctrine/instantiator ~1.0.1 -> no matching package found.

Fixes #7

I used XMLReader as I'm pretty sure that's everywhere theses days, and it doesn't have a __clone method.

The bug @whatthejeff mentioned (https://bugs.php.net/bug.php?id=53967) might bring further weirdness at some point, SplFileObject seems happy to be cloned if it's been instantiated using instantiator, but not if it's a "proper" instance?

PHP 5.6.0 (cli) (built: Oct  4 2014 20:41:37)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
    with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

<?php

require "vendor/autoload.php";

$instantiator = new \Doctrine\Instantiator\Instantiator();
$instance = $instantiator->instantiate('SplFileObject');

$b = clone $instance;

$a = new SplFileObject(__FILE__);
$b = clone $a;

PHP Fatal error:  main(): An object of class SplFileObject cannot be cloned in /Users/davem/src/instantiator/test.php on line 11
PHP Stack trace:
PHP   1. {main}() /Users/davem/src/instantiator/test.php:0

shell returned 255

A value object, mapped as embeddable, perfectly working:

<?php
class Foo {
    private ?string $bar = null;
    public function __construct(?string $bar) {
        $this->bar = $bar;
    }
}

But if you try to promote property:

<?php
class Foo {
    public function __construct(private ?string $bar = null) {
    }
}

It fails with Error: Typed property Foo::$bar must not be accessed before initialization as soon as you try to access property.

Property is not mapped.

Edit: tried to downgrade to Doctrine 2.8 to check if could be a problem with 2.9: no changes.

I think this was not Typehinted for BC break reasons but since in src/Doctrine/Instantiator/Instantiator.php the method instantiate calls the buildAndCacheFromFactory method where className is Typehinted as string , I don't see in which scenario $className could not be a string.

Moreover, in the interface the $className parameter is already described as string in the annotation.

If we accept classes that implement InstantiatorInterface but don't use a string as parameter (unlikely) then we need to remove the annotation. Right ?

Hello, i would like to use this package in a project where i serialize/deserialize entities in/from json file. I know that when applied to the full ORM it is up to the hydratator to populate the instantiated object with the right values respecting the mapping etc, but when used alone i feel that the package is missing the capability to populate the instantiated object with given values. What do you think about?

See #9

This PR is mainly tracking exotic classes with weird internal data-structures.

The test is mainly aimed at finding defects and/or unsupported classes, not really fixing anything within Instantiator itself.