On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil <pajou...@gmail.com> wrote:
> On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com
> <guilhermebla...@gmail.com> wrote:
> > Hi Dmitry,
> >
> >> Are you (and Doctrine team) interested in this annotation idea?
> >
> > I'd say that Benjamin nailed in our possible usage:
> >
> > <orm(new Entity("foo"))>
> > class Foo {
> > }
> >
> > Now I do feel we need to elaborate some sort of named parameters.
> Doctrine
> > tries to simplify a lot developer's life by using consistency in default
> > mapping and only if the user wants to override default behavior he needs
> to
> > override a given parameter. This means in a case where you're mapping a
> > JoinColumn (
> >
> https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
> > ),
> > you may only want to specify the onDelete="CASCADE" operation instead of
> > name, referencedColumnName and many other parameters.
> > Trying to map this in your default parameter passing, we'd have something
> > like:
> >
> > <orm(
> > [
> > new OneToOne("Address"),
> > new JoinColumn(default, default, default, default, "CASCADE")
> > ]
> > )>
> > public $address;
> >
> > As I said, named parameters make a lot of sense when mapping defaults.
> > Now by looking at this syntax, I still think we're closer to a simple
> array
> > implementation (ReflectionClass::getMetadata(string $name)) and having
> > something like:
> >
> > <[
> > "orm" => [
> > new OneToOne("Address"),
> > new JoinColumn(default, default, default, default, "CASCADE")
> > ]
> > ]>
> > public $address;
> >
> >
> > PS: We haven't even started on talking about overrides yet... =\
> >
>
> As a Doctrine user, I find this way worse than current state. This
> syntax looks UGLY and contains a lot of useless clutter. And yeah,
> adding named parameters to PHP be pretty helpful to make annotations
> more readable. :(
>
This is in no way related, only by the choice of guilherme's syntax. You
could
pass an array of options to the constructor to simulate named easily.
>
> And to what Francois said ("Anyway, I don't like the OO features
> people want to add everywhere. They can get strings and inject them to
> OO, but that's not the role of the annotation layer, IMHO. I
> definitely prefer the KISS approach."). What's exactly wrong with
> doing annotations in an object oriented manner? Both Doctrine
> Annotations and C# have them as objects, and it works well. Having
> annotations as just array of expressions/strings/whatever and needing
> another library to parse them is not really that great "upgrade" from
> current state. :(
>
PHP is not primarily an OOP language. As a user of Doctrine you wouldn't
need to care,
because we would wrap it anyway in our current code. So it wouldn't matter.
>
> Regards
> Pavel Kouril
>
