Hi,

I'm trying to install this repository using composer.

When I run composer require zendframework/zend-code, I get the following error.

  Problem 1
    - zendframework/zend-code 2.6.0 requires zendframework/zend-eventmanager ^2.6|^3.0 -> satisfiable by zendframework/zend-eventmanager[2.6.0].
    - zendframework/zend-code 2.6.1 requires zendframework/zend-eventmanager ^2.6|^3.0 -> satisfiable by zendframework/zend-eventmanager[2.6.0].
    - zendframework/zend-eventmanager 2.6.0 requires athletic/athletic dev-master -> no matching package found.
    - Installation request for zendframework/zend-code ^2.6 -> satisfiable by zendframework/zend-code[2.6.0, 2.6.1].

If I try to install zendframework/zend-eventmanager first, I still get an error.

How do I install zend-code?

As per PHP 7.1, it is possible to define nullability of a type by adding a ? in front of it ( https://wiki.php.net/rfc/nullable_types ).

A few heads-up:

• careful about ?Foo $bar = null vs ?Foo $bar vs Foo $bar = null
• need to eventually patch the TypeGenerator to include the ? in it (not sure yet)

The current code generator can generate:

• classes via ClassGenerator
• traits via TraitGenerator

an interface generator is currently missing.

Check code blocks are correct

TLDR; Check in all files that codeblocks are correct, in PSR-2 format and have PHP syntax highlighting applied.

Code blocks should be in the following format...

```php
 'ZEND-FRAMEWORK');

// No required options
$rendererOptions = array();
$renderer = Barcode::factory(
    'code39', 'image', $barcodeOptions, $rendererOptions
);

```

Note the three backticks then php in the opening fence, and the closing fence is just three backticks. It's common for the opening backticks to have no code type, or something like source.

Code should also have been automatically formatted into PSR-2 format, but sometimes these slip through the net.

As with PHP 7.0.5 the TokenArrayScanner is not working anymore with zend-code 2.
I have no further info, except that when using the FileScanner it does not produce any info when calling scan().

Basically, parsing via regexes is simply not acceptable/viable anymore, and absolutely doesn't scale, as the syntax of PHP keeps changing.

@asgrim has been building https://github.com/Roave/BetterReflection since last year, and the library is stable/mature, so I'd suggest that we chop the head off this part of zend-code's functionality.

Thoughts?

As per PHP 7.1, a new void return type is introduced ( https://wiki.php.net/rfc/void_return_type )

This basically means that the TypeGenerator needs to be patched to support void.

No further changes really needed in this component, as it doesn't really focus on method body generation.

Preparation

test.php:

<?php
spl_autoload_register(function () {});

run.php:

<?php
require_once __DIR__.'/vendor/autoload.php';
new \Zend\Code\Reflection\FileReflection('/test.php');

~> composer require zendframework/zend-code:3.0.2
~> php -v
PHP 7.0.7-4ubuntu2 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
    with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans

Execution

~> php run.php

Expected output

Nothing

Actual output

PHP Notice:  Uninitialized string offset: 1 in /vendor/zendframework/zend-code/src/Scanner/TokenArrayScanner.php on line 586

Notice: Uninitialized string offset: 1 in /vendor/zendframework/zend-code/src/Scanner/TokenArrayScanner.php on line 586

Is it possible to generate property without default value?

$x = new ClassGenerator;
        $x->setName('Classa');
        $x->addProperty('test');

Should output:

class Classa {
public $test;
}

Maybe there should be new type

TYPE_OMIT

Hi @veewee ,

there is an error within this fix: 4a6f4ab

if ClassNames with leading Backslash are used (i.E. \My\Base\Class), the returnvalue of the Method Zend\Code\Generator\ClassGenerator::generateShortOrCompleteClassname() will be \My\Base\Class

as a quickfix i would suggest something like following:

private function generateShortOrCompleteClassname($fqnClassName)
    {
        $parts = explode('\\', $fqnClassName);
        $parts = array_filter($parts);
        $className = array_pop($parts);
        $classNamespace = implode('\\', $parts);
        $currentNamespace = (string) $this->getNamespaceName();

        if ($classNamespace === $currentNamespace || in_array($fqnClassName, $this->getUses())) {
            return $className;
        }

        return '\\' . $fqnClassName;
    }

see the "array_filter()" method after explode

It is not possible to load a class that that extends or implements other classes without breaking the fully qualified names of the classes.

For example, if you load a reflection of this class

namespace Sample\ReflectionIssue;

class SampleClass
    extends \Sample\ReflectionIssue\ExtendableClass
    implements \Sample\ReflectionIssue\InterfaceClass
{ ... }

via $foo = ClassGenerator::fromReflection(ClassReflection(new \Sample\ReflectionIssue\SampleClass())); it will generate the following (invalid) output:

namespace Sample\ReflectionIssue;

class SampleClass
    extends Sample\ReflectionIssue\ExtendableClass
    implements Sample\ReflectionIssue\InterfaceClass
{ ... }

It's missing the leading backslash in front of the fully qualified class name.

PSR2 checking / fixing with phpcbf, flags up that the final method in a generated class has two clear linespaces after it, and that there are two clear linespaces after the class (at the end of the file).

Possibly the first self::LINE_FEED here is the cause of the linespaces after the final method, and the second in combination with this one gives the double lines at the end of the file?

Example of how to generate stuff like so...

ClassName::SOME_CONSTANT = ...

all I seem to manage is

'ClassName::SOME_CONSTANT' = ...

I would like to know how to do this and when I do I will add it as example to the documentation.

I'm getting Notice: Undefined offset: 1 in /path/to/vendor/zendframework/zend-code/src/Scanner/ClassScanner.php on line 596 using 3.1.0. It looks like this happens with aliased trait methods:

trait A 
{
    function a() {
        // does something
    }
}

class B 
{
    use A {
        a as b;
    }

    function a() {
        b();
        // do something more
    }
}

Stepping through the code it looks like $alias['original'] does not contain '::', causing the notice. I ran into this using zend-expressive-tooling on an existing project. It doesn't seem to cause anything other than annoyance, but I'm not sure if just adding a check for '::' would hide a deeper problem. Thoughts?

I just skimmed through the codebase of ZF2 and couldn't find scenarios where the "base" annotation parser of zend-code is used in it, except for zend-di. We could probably get rid of the entire Zend\Code\Annotation namespace.

While I realize that coming from me it sounds like I'm suggesting for people to just use doctrine/annotations, this part of the codebase really lies unused, and is a relatively complex layer that just proxies through to doctrine/annotations, in fact.

I propose deprecating it (probably 4.0) and dropping support for it in the subsequent major version. This allows us to also get rid of the zendframework/zend-eventmanager dependency inside zend-code.

If you attempt to include multiple traits across multiple use statements within a class, it will not be picked up by ClassScanner. This can be easily verified by modifying test/TestAsset/TestClassUsesTraitSimple.php and modifying it to use two use statements, one for each trait, rather than all in one use statement as it is now. It's worth noting that it doesn't appear to matter how many use statements there are, it will only ever record the traits available in the first statement.

I tried looking into why this was happening, but unfortunately the most sophisticated debugging tools I have available to me at the moment are echo and var_dump. From what I can tell, the parser does find the other use statements, and is even able to work out what the class name is, but it never ends up permanently in $this->infos.

Hi,

I received a bug report on doctrine/doctrineMigrationsBundle for an elusive bug that only happen on windows. It looks like this code line is the cause of the issue. https://github.com/zendframework/zend-code/blob/master/src/Generator/MethodGenerator.php#L96

I guess that the assumption is that the first line will always be an empty one (aka only containing a new line). It works perfectly on linux but on windows the explode call might return the whole body of the function as one line. Explode will never find the windows line ending (\r\n) if the code was build on linux.

From that assumption, the issue could be fixed just by replacing the the PHP_EOL param with "\n" but I don't know what kind of side effect the trailling "\r"might cause.

Thanks for your time

After success installation message, while launching admin/frontend getting this error

I'm using PHP on windows but have set IDE intentionally to make unix new lines \n, not windows ones \r\n.
When running FileGenerator::fromReflectedFileName() on such file, I got exception

Undefined offset: 1

D:\www\home\tmilos\model\vendor\zendframework\zend-code\src\Generator\MethodGenerator.php:98
D:\www\home\tmilos\model\vendor\zendframework\zend-code\src\Generator\MethodGenerator.php:77
D:\www\home\tmilos\model\vendor\zendframework\zend-code\src\Generator\ClassGenerator.php:146
D:\www\home\tmilos\model\vendor\zendframework\zend-code\src\Generator\FileGenerator.php:96
D:\www\home\tmilos\model\vendor\zendframework\zend-code\src\Generator\FileGenerator.php:77

Tested on zendframework/zend-code v3.0.1

Debuging shows the source of the problem is with inconsistent line endings in the project:

1. During loading MethodReflection::extractMethodContents() implodes lines with \n

2. While MethodGenerator::clearBodyIndention() explodes what MethodReflection did before with PHP_EOL

So, it seems this lib will work only if PHP_EOL === "\n" and guess that excludes php windows builds.

It would be nice you fix that and use consistent line endings.

I scan with this class a directory for classes. But getClasses returns an empty array. When I test getFiles it works I get dozens files. I use php7.

As the subject says, unlike most methods in that class, getTraitNames() does not call scan() before checking available data. This means that if you call getTraitNames() or getTraits() as the first action on a newly-instantiated ClassScanner, you won't get any traits, depsite there being traits.

Unless someone confirms that this is intended behaviour and isn't actually a bug, I'll happily submit a PR to fix the issue.

Check docs for other problems

TLDR; Cast your eye over the documetation for any problems not covered in the other issues

Things slip through the net, so check the documentation for other problems that have been missed. Common other problems include

• Bullet lists (should be single * then space at the start of line)
• Inline code - should be marked by three backticks at start and finish
• bookdown.json file is correctly formated and has the right escaping
• Links between documentation using RST have been stripped
• Any other RST has been removed correctly
• Anything and everything not covered

If you end up fixing the same problem over and over, please ping Gary Hockin - we may be able to add bespoke issue for that problem, or fix in automated capacity

Check headers are correct

TLDR; Headers should use the #, ## etc to format different levels of headers, and not be underlines using ===== or ``-----`, or be psuedo header using bold

Check all headers on the documentation - headers should use the hash style of declaration rather then be underlined with equals or dashes. The more hashes, the more of a subheading. Eg:

• # is equal to <h1>
• ## is equal to <h2>
• ### is equal to <h3>
• #### is equal to <h4>
• ##### is equal to <h5>

Headings should be appropriate for their level in the documentation.

Psuedo headers using bold tags ** should be replaced with appropriate level of heading tag.

Why there is no support for php 7.0.5 in the current master? Is this a typo, or something in 7.0.5 breaks the code?

short example

 Interface A {  }
 Interface B {  }
 Interface C extends A,B {  }

 $fileScanner = .....; // a file which contains Interface C
 $clazz = $fileScanner->getClasses()[0]; //which is C

 $clazz->getInterfaces(); // this line don't work correctly. It should return A and B

best regards
Siwapun Siwaporn

Check the document for bad blockquoutes

TLDR; Check blockquotes are formatted correctly using > and check headings in blockquotes are using ###

Blockquotes are donated by a single greater than character and then a space. Make sure all the blockquotes in every doc file are correctly formatted. Headings in blockquotes should use ### and not bold.

Any paragraph spacing in blockquotes should be marked using a single greater than, then a space.

Unless I'm missing something, there is no way to add a type-hinted parameter to a method that does not use the fully-qualified name (as it exists as a use statement).

e.g. (See SomeClass type-hint in method)

use Foo\Bar\SomeClass;

class GeneratedClass
{
    public function generatedMethod(SomeClass $instance) {
    }
}

If you don't supply a fully-qualified name, it looks like:

use Foo\Bar\SomeClass;

class GeneratedClass
{
    public function generatedMethod(\SomeClass $instance) {
    }
}

Related to #96, PropertyGenerator behaves incorrectly when the default value passed into it is a ValueGenerator instead of a PropertyValueGenerator.

Example (lifted from #96):

<?php
<<<CONFIG
packages:
    - "zendframework/zend-code: ^3.0"
CONFIG;

$classGenerator    = new \Zend\Code\Generator\ClassGenerator();
$propertyGenerator = new \Zend\Code\Generator\PropertyGenerator();
$value             = new \Zend\Code\Generator\ValueGenerator();
$value->setValue('DefaultString');
$value->setType(\Zend\Code\Generator\ValueGenerator::TYPE_STRING);
$propertyGenerator->setName("foo");
$propertyGenerator->setDefaultValue($value->generate());

$classGenerator->addPropertyFromGenerator($propertyGenerator);

print $classGenerator->generate();

Will print this:

class 
{

    public $foo = '\'DefaultString\'';


}

PropertyGenerator::setDefaultValue wraps everything that isn't a PropertyValueGenerator instance in a new instance of that class. IMO setDefaultValue should not accept ValueGenerator instances or at least convert to a PropertyValueGenerator, vs composing one into the other as is presently the case. This change does break BC, however.

The Zend\Code\Generator\ValueGenerator cannot generate arrays with the short array syntax.

In lines https://github.com/zendframework/zend-code/blob/master/src/Generator/ValueGenerator.php#L346 and https://github.com/zendframework/zend-code/blob/master/src/Generator/ValueGenerator.php#L382 the long array syntax is hard-coded.

Would be nice to have this configurable.

src/Generator/MethodGenerator.php -> clearBodyIndention (lines 90 to 109)

is trying to parse the following body:

array (size=1)
0 => string ' return $this->getServiceLocator()->get('Core\Page\Service\PageService');' (length=86)

(this is a vardump of the result from the explode on line 96)

this method asumes that all my functions have an enter at the first line, I'd suggest to make this method a tad bit smarter so that it is able to work when you have a oneliner, like I have in my case.

zendframework-zend-code-001.txt

This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/4149
User: @Ocramius
Created On: 2013-03-30T11:59:09Z
Updated At: 2014-09-28T00:34:50Z
Body
This PR introduces FQCNs for type-hints in generated method signatures. This is a BC break, but it is necessary to use the code generator when the generated code is not placed on a dedicated file.

Before:

public function doFoo(Foo $foo) {}

After

public function doFoo(\Foo $foo) {}

This PR also takes into account the new PHP 5.4 callable data type when generating code.

Comment

User: @Ocramius
Created On: 2013-04-08T14:28:13Z
Updated At: 2013-04-08T14:28:13Z
Body
@prolic ping? You used Zend\Code quite a bit - is this a huge BC break for you?

Comment

User: @prolic
Created On: 2013-04-08T23:02:49Z
Updated At: 2013-04-08T23:02:49Z
Body
I am okay with these changes. This helps in more situations as I would expect troubles with it.

Comment

User: @weierophinney
Created On: 2013-04-12T16:36:04Z
Updated At: 2013-04-12T16:36:04Z
Body
Would it be possible to make this optional via a flag?

I ask, because our own CS indicates that parameter type hints should not be fully qualified; they should always resolve to current imports. The use case you're specifying here is highly specific -- it's for when classes are not in dedicated files, which, again, was not the original purpose, and goes against our own CS and recommendations.

That said, I can see the rationale for having this, but doing it as an optional behavior makes more sense to me.

Comment

User: @Ocramius
Created On: 2013-04-12T16:38:03Z
Updated At: 2013-04-12T16:38:03Z
Body
I'll think of a way of making this optional. The fact is that this currently makes it impossible to have classes generated via generate() without a filegenerator too (for eval'd code)

Comment

User: @icywolfy
Created On: 2013-04-16T16:57:20Z
Updated At: 2013-04-16T16:57:20Z
Body
Why would one need to use FQCN when multiple classes are in the same file/eval'd code?
So long as each section is prefixed with a non-global namespace; there's no issue with conflicting uses/namespaces.
And if you need to use the global namespace, then bracketed notation is better.

so

namespace Foo;
class A {}

namespace Foo;
use Foo\A as Bar;
class C extends Bar {}

namespace Foo;
interface B {}

namespace Foo\Bar\Baz;
use Foo\A as Baz;
use Foo\B as Bar;

class C extends Baz implements Bar {}

or if you need global support: (this isn't supported in the ClassGenerator)

namespace Foo {
class A{}
}
namespace {
use Foo\A as Bar;
class B extends Bar {}
}
namespace Foo {
use B as Bar;
class B extends Bar {}
}

But, I would personally see the above generated/used rather than giving users the option of using FQCN, since it's still much better to be using Use statements if only to promote better coding habits.

But that said, I have had no issues generating multiple classes into a single cached-file, or dynamic unclusion via eval() at work (hate using eval, but since the temporary classes don't live in the filesystem, can't really auto-load it)

Comment

User: @Ocramius
Created On: 2013-04-16T21:26:17Z
Updated At: 2013-04-16T21:26:17Z
Body
@icywolfy this causes a number of problems atm.

Just as a simple example, take multiple imported classes with the same name.

Using the FQCN is not better from a CS perspective, but honestly, nobody should ever care about generated code CS.

Comment

User: @icywolfy
Created On: 2013-04-16T23:05:33Z
Updated At: 2013-04-16T23:05:33Z
Body
@Ocramius Perhaps, but just don't see the issues with

    $x = new ClassGenerator('A');
    $x->setNamespaceName('Foo\Bot');
    $x->addUse('Foo\Bar\A', 'BarA');
    $x->addUse('Foo\Baz\A', 'BarB');
    $x->addUse('FooBar');
    $x->addMethod('doSomething', array(
      new ParameterGenerator('barA', 'BarA'),
      new ParameterGenerator('bazA', 'BazA'),
      new ParameterGenerator('botA', 'A'),
      new ParameterGenerator('subBotA', 'Sub\A'),
    ));
    $x->addMethod('somethingElse', array(
      new ParameterGenerator('barA', 'BarA'),
      new ParameterGenerator('api', 'FooBar\Service\ApiInterface $api'),
   ));

Or if you need to use a FQCN, explicitly prepend add the '' during generation;
(we just "use" our global and vendor prefixes namespaces)

Though I would love to have it propagate use-aliases set against methods; so that you can define the aliases you use in the method-body and have it resolve up to the class-level and be added to the generator (and throw exception if conflicting use-aliases are used)

But, we here heavily use the generated code for both sub-project generation, and for use of user and type management; User's are generated upon major changes, types are rebuilt/committed to code-base based on the config files.

We do manual changes for people to meet their desired behaviours and mark their classes as manually edited, and then treat them specially until such time that it's properly incorporated into the build/generation process. But since we are actually using\editing the generated code, it's nice to have it be readily readable.
Though fundamentally I'm against BC breaks now that ZF2 is relatively stable in the 2.1.x branch.

# <user>.php :
namespace <type>\<user>;
use <type>\User as BaseUser;

class User extends BaseUser {
   private $manualEdit = false;
   function getRole() { ...  return new Role\BaseRole()  }
   function hasRole($roleName) { return class_exists(Role\<$roleName>); }
...
}

namespace <type>\<user>\Role;
use <type>\<user> as BaseUser;
use <type>\TypeInterface;
class BaseRole implements TypeInterface { ... }

namespace <type>\<user>\Contact;
use ...
class Address extends Address\<country> { ... }

(we are operating without access to a database for several of the East-coast data-centres, and this was the solution that was ended up on, it's actually quite nice, if not a bit unconventional. Damned lawyers dictating how things work.)

Comment

User: @Ocramius
Created On: 2013-04-17T07:42:23Z
Updated At: 2013-04-17T07:42:23Z
Body
That's way too complex for no real reason. Having FQCN simply removes all these problems at once. I'll see about the break - for now I had to subclass ALL generators to get rid of the problem, since the current API is unusable.

Comment

User: @ralphschindler
Created On: 2013-06-06T22:48:45Z
Updated At: 2013-06-06T22:48:45Z
Body
@Ocramius after a cursory review, I'm ok with this, do you still feel like this should be merged?

Comment

User: @Ocramius
Created On: 2013-06-06T23:13:21Z
Updated At: 2013-06-06T23:13:46Z
Body
@ralphschindler not sure since it's a bc break. Gimme some more time, otherwise feel free to close this and I'll redo it somehow.

Comment

User: @EvanDotPro
Created On: 2013-10-15T03:05:44Z
Updated At: 2013-10-15T03:05:44Z
Body
@Ocramius ping? Let's either get this merged or refactored. 😄

Comment

User: @Ocramius
Created On: 2014-02-04T12:05:50Z
Updated At: 2014-02-04T12:05:50Z
Body
This cannot land in 2.x - I'll keep my adaptation in my library and the issue open since it's a quite relevant "bug"

Comment

User: @weierophinney
Created On: 2014-03-03T16:31:55Z
Updated At: 2014-03-03T16:31:55Z
Body
Marking for 3.0.0

Is there currently a way to add declare(strict_types=1); to a generated file?

I couldn't see a suitable method in the FileGenerator, and wasn't sure where else something like this might be hiding.

I had requested traits back in zendframework/zendframework#4876 which is now closed. It appears this support was added via TraitGenerator. Would be great to see some examples included in the docs.

This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7113
User: @nouc23
Created On: 2015-01-09T10:38:17Z
Updated At: 2015-05-07T14:11:59Z
Body
I know we should write code using PSR standard but life is different.
While we use tabs script ignore annotations.

Fixes #5595

Comment

User: @Ocramius
Created On: 2015-01-09T10:38:57Z
Updated At: 2015-01-09T10:38:57Z
Body
This requires a test asset containing tabs, and a related test

Comment

User: @nouc23
Created On: 2015-01-09T10:58:53Z
Updated At: 2015-01-09T10:58:53Z
Body
done

Comment

User: @weierophinney
Created On: 2015-02-19T20:50:49Z
Updated At: 2015-02-19T20:50:49Z
Body
Needs:

• Rebase
• new test.

Comment

User: @Maks3w
Created On: 2015-05-07T13:57:11Z
Updated At: 2015-05-07T13:57:11Z
Body
I've pulled this and found the test is not related with the change made in scanner. So I don't know what is trying to fix this. Test never fails.

Comment

User: @nouc23
Created On: 2015-05-07T14:11:59Z
Updated At: 2015-05-07T14:11:59Z
Body

I edit existing test, and I was told to create new one.

I forgot to do that and also I doesnt use github much. I try to finish this up on days.

Wysłano z aplikacji myMail dla Androida
czwartek, 07 maja 2015, 03:57PM +02:00 od Maks3w [email protected]:

I've pulled this and found the test is not related with the change made in scanner. So I don't know what is trying to fix this. Test never fails.
—
Reply to this email directly or  view it on GitHub .

Check the tables in a document

TLDR; All tables should be in the format of GHFM using | and - as horizontal and vertical separators respectively

Check all tables are in the correct format. Please don't use leading and trailing | - more information on github flavoured markdown tables can be found here.

After updating zend-code to version 3.0.3 through composer update the following error is thrown upon clearing the Symfony cache:

Fatal error: Uncaught Symfony\Component\Debug\Exception\FatalThrowableError: Parse error: syntax error, unexpected '\' (T_NS_SEPARATOR), expecting identifier (T_STRING) in [...]var/cache/dev/appDevDebugProjectContainer.php:7161

Here's the corresponding line of code:
class VichUploaderBundleHandlerUploadHandler_000000003557d388000000006581de10da75941a549785cf26d7df71050c90e4 extends \\Vich\UploaderBundle\Handler\UploadHandler implements \\ProxyManager\Proxy\VirtualProxyInterface {

Reverting zend-code back to 3.0.2 through composer.json fixes the above issue.

Since the docs are located elsewhere this repo's empty wiki should be disabled.

HI,
I have issue with Ocramius/ProxyManager package. This package require to zendframework/zend-code and guys from Ocramius/ProxyManager asked me to reported about this issue to you.
You can read about issue here Ocramius/ProxyManager

Thanks

This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7428
User: @stepashka69
Created On: 2015-04-07T13:11:58Z
Updated At: 2015-11-06T21:16:27Z
Body
Hello,

The problem is that sometimes the function returns array and sometimes (when there are not traits) null.
It would be also nice to have a phpdoc for the function.

The problem was caught on the following code:

// $class is an instance of ClassReflection
foreach ($class->getTraits() as $trait) {
//...
}

The code gives PHP error "Invalid argument supplied for foreach()" when there are no traits in the class.

The problem is in file ClassReflection.php line 185 . It returns null but it will be more logical to return $vals (empty array at that stage).

    public function getTraits()
    {
        $vals = array();
        $traits = parent::getTraits();
        if (! $traits) {
            return; // It would be better to return $vals here
        }

        foreach ($traits as $trait) {
            $vals[] = new ClassReflection($trait->getName());
        }

        return $vals;
    }

Comment

User: @samsonasik
Created On: 2015-04-07T15:41:42Z
Updated At: 2015-04-07T15:41:42Z
Body
linked with #7431

I've been working on this in Ocramius/ProxyManager#241, but then figured out that I really needed to upgrade the core package.

There are some areas of the code that will be affected by BC breaks, and therefore this needs to go in 3.0.0:

• this docblock stuff needs to die (causes bugs)
• removing PHP5 support (maintaining compatibility with PHP5 is more than problematic, after a first skim of the test suite)

I'm willing to take on this piece of work, and will likely send in an example patch tomorrow.

I use the zend annotation module, it scans the whole Module directory with this the ClassScanner class from this module. In the config directory it writes some notices to the output - I can't avoid this without raise the php log level, so I think it's an issue of this module to avoid that output.

Notice: Uninitialized string offset: 1 in /.../vendor/zendframework/zendframework/library/Zend/Code/Scanner/ClassScanner.php on line 974

Notice: Uninitialized string offset: 1 in /.../vendor/zendframework/zendframework/library/Zend/Code/Scanner/ClassScanner.php on line 974

Notice: Uninitialized string offset: 1 in /.../vendor/zendframework/zendframework/library/Zend/Code/Scanner/ClassScanner.php on line 974

Notice: Undefined offset: 267 in /.../vendor/zendframework/zendframework/library/Zend/Code/Scanner/ClassScanner.php on line 942

Notice: Undefined offset: 681 in /.../vendor/zendframework/zendframework/library/Zend/Code/Scanner/ClassScanner.php on line 942

The PHP version that is required on the composer.json accepts PHP 7.0.0 until 7.0.4, ignores PHP 7.0.5 and accepts 7.0.6 and above. PHP 7.0.6 wasn't even released yet.

    "php": "^5.5 || 7.0.0 - 7.0.4 || ^7.0.6",

The ParameterGenerator always considers ReflectionParameter#isOptional() when checking for default parameter values.

A variadic argument is, though, always optional and never has a default value.

This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/6503
User: @rahuldroy
Created On: 2014-07-31T14:24:38Z
Updated At: 2015-05-07T13:37:25Z
Body

Comment

User: @Ocramius
Created On: 2014-07-31T15:11:25Z
Updated At: 2014-07-31T15:11:25Z
Body
Linking #6499

Comment

User: @weierophinney
Created On: 2014-08-07T16:42:14Z
Updated At: 2014-08-07T16:42:14Z
Body
@Ocramius is this an issue specific to our annotation support, or is it an issue in the Doctrine annotation library?

Comment

User: @Ocramius
Created On: 2014-08-07T16:49:09Z
Updated At: 2014-08-07T16:49:09Z
Body
Still not clear. I personally think Zend\Code may be passing a different string to the annotation parser.

Comment

User: @weierophinney
Created On: 2014-08-07T17:04:10Z
Updated At: 2014-08-07T17:04:10Z
Body
Removed milestone, as we cannot reliably reproduce.

In discussion with @Ocramius, it's possible that Zend\Code is passing an invalid string to the annotation parser. In looking at Zend\Code\Reflection\ClassReflection, however, the method we call is getAnnotations(), which passes the results of getDocComment() -- which is inherited directly from ReflectionClass. As such... this is very difficult to track.

Comment

User: @nickurt
Created On: 2014-08-08T08:45:05Z
Updated At: 2014-08-08T08:45:05Z
Body
@weierophinney @Ocramius Thanks for the reply's, I debugged some things.

The file Zend\Code\Scanner\AnnotationScanner -> __construct returns the correct docComment, but it fails in the tokenize function (#ref).

The currentChar (#ref) is here ...

string(1) "/"
string(1) "
"
string(1) " "
string(1) "
"
string(1) " "
string(1) "
"
string(1) " "
string(1) "
"
string(1) " "
string(1) "
"
string(1) " "
string(1) "
"
string(1) " "

Comment

User: @Ocramius
Created On: 2014-11-19T22:24:09Z
Updated At: 2014-11-19T22:24:09Z
Body
I see that this has indeed nothing to do with doctrine/annotations. Removing myself from the assignees as I cannot help with this issue right now.

Comment

User: @Maks3w
Created On: 2015-05-07T13:37:25Z
Updated At: 2015-05-07T13:37:25Z
Body
Do zendframework/zendframework#7113 fix this?

I'm trying to set array for default value:

public function exportCategory($sourceId, $targetParentId, $params = [1, 2, 3])

And getting notice:

Notice: Undefined index: type in /home/forever/prj/Enterum/vendor/zendframework/zend-code/src/Scanner/MethodScanner.php on line 322

25  0.2380  7434808 KJSencha\Direct\Remoting\Api\Factory\ApiBuilder->buildAction( ) .../ApiBuilder.php:138
26  0.2551  7955224 KJSencha\Direct\Remoting\Api\Factory\ApiBuilder->buildMethod( ) .../ApiBuilder.php:162
27  0.2551  7955352 Zend\Code\Scanner\MethodScanner->getNumberOfParameters( )   .../ApiBuilder.php:178
28  0.2551  7955352 Zend\Code\Scanner\MethodScanner->getParameters( )   .../MethodScanner.php:308

Below is a piece of ApiBuilder.php:

/**
 * Builds and populates Action object based on the provided class name
 *
 * @param  string $className
 * @return Action
 */
public function buildAction($className)
{
    $classReflection = new ClassReflection($className);
    $scanner = new FileScanner($classReflection->getFileName(), $this->annotationManager);
    $classScanner = $scanner->getClass($classReflection->getName());
    $action = new Action($classScanner->getName());

    foreach ($classScanner->getMethods() as $classMethod) {
        if ($classMethod->isPublic() && $classMethod->getName() != '__construct') {
            $action->addMethod($this->buildMethod($classMethod));
        }
    }

    return $action;
}

/**
 * Builds a method object based on the provided method scanner
 *
 * @param  MethodScanner $classMethod
 * @return Method
 */
protected function buildMethod(MethodScanner $classMethod)
{
    $method = new Method($classMethod->getName());
    $method->setNumberOfParameters($classMethod->getNumberOfParameters());

    // Loop through annotations
    if ($annotations = $classMethod->getAnnotations($this->annotationManager)) {
        foreach ($annotations as $annotation) {
            // @todo annotations should implement some kind of interface?
            if (method_exists($annotation, 'decorateObject')) {
                $annotation->decorateObject($method);
            }
        }
    }

    return $method;
}

With $params = [1,2], for example, notice disapears.

I believe the issue is with MethodScanner and not ParameterScanner, as this is what is actually parsing the PHP tokens - it correctly ignores non-scalar type declarations such as array and callable. From what I can tell, string, int, bool and float are tokens of type T_STRING. As a result, the scanner believes they are classnames. This can result in classnames that simply don't exist.

I'm not really sure how this can be worked around inside the scanner. As far as I can tell, no PHP version checks are performed on the code being parsed, which means there's no reliable way of detecting whether or not string is an actual classname in PHP <7.0 code, or a scalar type declaration in PHP >=7.0 code.

Perhaps there needs to be some way to globally set the PHP version of the code being scanned?

From zendframework/zendframework#6860 which was just closed:

It looks like FileReflection uses token_get_all(file_get_contents($file)) to actually scan the file, so I am a little lost by the requirement of includeing it.

I am trying to fix some PHP classes programmatically, all of which have the same class name in the global namespace. To do this I was planning to reflect the files, get the class reflection, and instantiate the class generator from that to make my changes. Of course, since reflecting the file requires including it, I cannot do this right now, as it would have to re-declare the classes.

/cc @sasezaki @adamlundrigan who had activity on previous issue

Notice: Undefined offset: 585 in /var/www/.../current/vendor/zendframework/zend-code/src/Scanner/ClassScanner.php on line 939

Notice: Uninitialized string offset: 1 in /var/www/.../current/vendor/zendframework/zend-code/src/Scanner/ClassScanner.php on line 971

Notice: Uninitialized string offset: 1 in /var/www/.../current/vendor/zendframework/zend-code/src/Scanner/ClassScanner.php on line 971

Notice: Uninitialized string offset: 1 in /var/www/.../current/vendor/zendframework/zend-code/src/Scanner/ClassScanner.php on line 971

Notice: Undefined offset: 267 in /var/www/.../current/vendor/zendframework/zend-code/src/Scanner/ClassScanner.php on line 939

BTW: I just added a new directory to scan via the great zend annotation module but it fails with a fatal exception in the ClassScanner. Is it possible to add more accurate error messages which make it simple to locate the file?

edit:

• Error when folder contains empty file.
• Notice:

Notice: Uninitialized string offset: 1 in /var/www/.../current/vendor/zendframework/zend-code/src/Scanner/TokenArrayScanner.php on line 582 Notice: Uninitialized string offset: 1 in /var/www/.../current/vendor/zendframework/zend-code/src/Scanner/TokenArrayScanner.php on line 582

when you have a php config file with ::class syntax:

<?php

return [
    'xxxx' => [
        'zzzz' => [
            'source_class' => \Test\Bla::class
        ]
    ]
];

Hi,

I think that Classgenerator should support docblock for constants . Ex :

<?php

namespace Participation\Controller;

class IndexController extends \CS\ZF2\Core\Mvc\Controller\AbstractActionController
{

    /**
     * @var string
     */
    const STEP_CONTACT_OK = 'CONTACT_OK';