DDC-2031: doctrine:generate:entities - Alternate (scoped) Namespace Syntax not supported #2563

New Issue

admin · 2026-01-22T13:57:04+01:00

admin commented

2026-01-22 13:57:04 +01:00

Originally created by @doctrinebot on GitHub (Sep 13, 2012).

Originally assigned to: @Ocramius on GitHub.

Jira issue originally created by user ilaurillard:

My preferred Syntax:

namespace foo
{
use ...;
class { ... }
}

seems not to be supported.

Setters/Getters are inserted before the last curly closing bracket - but that is the closing Namespace scope!

Originally created by @doctrinebot on GitHub (Sep 13, 2012). Originally assigned to: @Ocramius on GitHub. Jira issue originally created by user ilaurillard: My preferred Syntax: namespace foo { use ...; class { ... } } seems not to be supported. Setters/Getters are inserted before the last curly closing bracket - but that is the closing Namespace scope!

admin added the Bug label 2026-01-22 13:57:04 +01:00

admin closed this issue

2026-01-22 13:57:05 +01:00

admin commented

2026-01-22 13:57:05 +01:00

@doctrinebot commented on GitHub (Sep 13, 2012):

Comment created by @ocramius:

[~ilaurillard] entities are per-file anyway, you'd have only one namespace.

namespace Foo
{
    use AAA;
    class Bar {}
}

is exactly like writing

namespace Foo
use AAA;
class Bar {}

@doctrinebot commented on GitHub (Sep 13, 2012): Comment created by @ocramius: [~ilaurillard] entities are per-file anyway, you'd have only one namespace. ``` namespace Foo { use AAA; class Bar {} } ``` is exactly like writing ``` namespace Foo use AAA; class Bar {} ```

admin commented

2026-01-22 13:57:06 +01:00

@doctrinebot commented on GitHub (Sep 14, 2012):

Comment created by ilaurillard:

One namespace per file may be correct, but only considering autoloading issues.
Have a look to the symfony "bootstrap.php.cache" file for an example of multiple namespace and classes.
Doctrine should have a similar "compiling" option.

I know of the standard syntax - thats why i wrote: "my preferred syntax".

I just may live with the standard syntax - you may want to at least mention in the docs that you have to use standard syntax, else your compiled entities fatal.

@doctrinebot commented on GitHub (Sep 14, 2012): Comment created by ilaurillard: One namespace per file may be correct, but only considering autoloading issues. Have a look to the symfony "bootstrap.php.cache" file for an example of multiple namespace and classes. Doctrine should have a similar "compiling" option. I know of the standard syntax - thats why i wrote: "my preferred syntax". I just may live with the standard syntax - you may want to at least mention in the docs that you have to use standard syntax, else your compiled entities fatal.

admin commented

2026-01-22 13:57:07 +01:00

@doctrinebot commented on GitHub (Sep 14, 2012):

Comment created by @ocramius:

[~ilaurillard] not really sure classcache is doctrine's problem. Playing with reflection, any third party (Symfony2 here) can handle that without string concat

@doctrinebot commented on GitHub (Sep 14, 2012): Comment created by @ocramius: [~ilaurillard] not really sure classcache is doctrine's problem. Playing with reflection, any third party (Symfony2 here) can handle that without string concat

admin commented

2026-01-22 13:57:07 +01:00

@doctrinebot commented on GitHub (Sep 14, 2012):

Comment created by stof:

@Marco The issue is not about creting a class cache but about editing entities with the EntityGenerator when the code uses the syntax with braces.

@doctrinebot commented on GitHub (Sep 14, 2012): Comment created by stof: @Marco The issue is not about creting a class cache but about editing entities with the EntityGenerator when the code uses the syntax with braces.

admin commented

2026-01-22 13:57:07 +01:00

@doctrinebot commented on GitHub (Sep 14, 2012):

Comment created by @ocramius:

[_{stof] yes, but I think the code generator becomes quite too complex when we add all these details... What I was thinking is that using an alternate syntax to ease the task [}ilaurillard] exposed as an example is anyway a bit weak. I don't see this coming without code generation projects going on first.

@doctrinebot commented on GitHub (Sep 14, 2012): Comment created by @ocramius: [<sub>stof] yes, but I think the code generator becomes quite too complex when we add all these details... What I was thinking is that using an alternate syntax to ease the task [</sub>ilaurillard] exposed as an example is anyway a bit weak. I don't see this coming without code generation projects going on first.

admin commented

2026-01-22 13:57:08 +01:00

@doctrinebot commented on GitHub (Jan 23, 2013):

Comment created by @ocramius:

Alternate code generators project is not yet on roadmap.

@doctrinebot commented on GitHub (Jan 23, 2013): Comment created by @ocramius: Alternate code generators project is not yet on roadmap.

admin commented

2026-01-22 13:57:08 +01:00

@doctrinebot commented on GitHub (Jan 23, 2013):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Jan 23, 2013): Issue was closed with resolution "Won't Fix"

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#2563