Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52327
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=jHbohImhuSzkIPcDY5Wz5+BX/VcWOEtUWyk5QHloVTr9lfjsCcB+RmxTmUoccjefz5
         F07Z0zioviQIcS6uQLZhryUl2YLbug2c4VoJ3eEd1UNJBRLBy10RKXoV0pdwNdGnKEJf
         gQZ5GwWsAveKikrpyTogovCbql35Mgk8KbEzo=
MIME-Version: 1.0
In-Reply-To: <BANLkTim7r0nKw0RJV=_-cSceGeGc6u0Pdg@mail.gmail.com>
References: <BANLkTinO0h7020fs+PLjM0fUmMjQXoTsyw@mail.gmail.com>
 <BANLkTim8p7A5+svvjZw6rc_KE+tBMnOsjw@mail.gmail.com> <4DC826B1.4090806@lerdorf.com>
 <BANLkTikpLY+AntSrNi91rzGNZi4FkPrSwA@mail.gmail.com> <4DC82A36.8090604@lerdorf.com>
 <BANLkTi=aLVw8KqOV_jb9dBm=XqX6TqTVwA@mail.gmail.com> <4DC83401.2090202@sugarcrm.com>
 <BANLkTiniayhZ+8CRQjPFBDLOBu=E7UUv=A@mail.gmail.com> <BANLkTimvE1nE+UOv+8hUaPiyfozn3PgU3Q@mail.gmail.com>
 <BANLkTinfEFsiSWOi3RgjZ4-6QeNjRVMwTQ@mail.gmail.com> <4DC8D122.3050507@lsces.co.uk>
 <BANLkTim1euVOKXxLc3FdhJAywqnPHDkbwg@mail.gmail.com> <BANLkTi=AxkZf_jMUJ0MaRREVX9t33Ex0Zw@mail.gmail.com>
 <4DC8F125.2010503@toolpark.com> <BANLkTim5MbJV29xjx3b3+9VofVuCKVhh3g@mail.gmail.com>
 <4DC947E3.8070606@toolpark.com> <BANLkTinaejEAznJoyuk09jrB2TroDk+A+A@mail.gmail.com>
 <4DC9B62C.2040009@toolpark.com> <BANLkTikaM+m+Pd125q16xdncm067KHizJg@mail.gmail.com>
 <4DCA2E26.5010202@toolpark.com> <BANLkTim7r0nKw0RJV=_-cSceGeGc6u0Pdg@mail.gmail.com>
Date: Wed, 11 May 2011 16:54:06 -0500
Message-ID: <BANLkTinZf9TY5k9RQDDMWMrd6pASQtYuFA@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: Lars Schultz <lars.schultz@toolpark.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=001636eee3dcc0cb9904a3071d92
Subject: Re: [PHP-DEV] annotations again
From: dukeofgaming@gmail.com (dukeofgaming)

--001636eee3dcc0cb9904a3071d92
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, May 11, 2011 at 12:29 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> Hi Larz,
>
> On Wed, May 11, 2011 at 3:35 AM, Lars Schultz <lars.schultz@toolpark.com>
> wrote:
> > Am 11.05.2011 00:28, schrieb guilhermeblanco@gmail.com:
> >>
> >> - Entities with knowledge about its persistence information
> >
> > That must be something I simply have no knowledge about. But isn't it
> just a
> > theoretical difference, because in practice, the "code" being annotatio=
ns
> or
> > PHP-Code is kept within the class, therefore the entity is not separate=
d
> > from its persistence information...but then I don't really understand t=
he
> > problem in the first place;)
> >
>
> I hope you have OO architecture knowledge.
> By having entity implementing an interface/abstract class, you make
> your domain classes depending on persistence package.
> This dependency breaks OO encapsulation of packages.
>
> By having the code (annotations) within the class you just meta
> classify each property/method of your class.
> You probably don't know, but annotations that you use in Doctrine
> follows a standard document usually referred as JPA (or JSR-317),
> second version.
> So, you may be surprised, but any persistence tool that follows this
> document would be able to support this Entity. One good example is how
> ORM package of Doctrine works and you're able to have your Entity
> "schemaless" with almost 0 changes in ODM package (read as CouchDB and
> MongoDB).
>

I think part of the problem on the discussion =97regarding the acceptance o=
f
the feature=97 is that annotations are being seen just as a "cute feature",
instead of an architectural advantage to all good PHP code (i.e. OO taking
advantage of design patterns) and its implications. In summary: they are
huge. If simple reflection can tell the developers what the code is,
annotations let them know what it can be in depending on their context (i.e=
.
behavior is decoupled).


> >> - Resources being wasted
> >
> > Now you sound like Rasmus when he talks about his assembly-history. Do
> you
> > really expect Annotations to perform better than hard-wired php-code?
> >
>
> Yes, and built-in support is WAY faster.
>

If I'm not mistaken, the current comment-parsing solutions are so slow that
the annotated classes and methods and attributes *NEED* the metadata to be
cached in separate PHP code in order to function, otherwise it would be
practically impossible to use them in production sites; conversely, if they
were supported natively caching would not be absolutely necessary. Is this
the case?, if so, I think it is a strong use case to be considered for the
RFC.

BTW, why is it rejected in the wiki now?. Is it completely completely
rejected?, or just postponed?... if it is just cataloged as declined for
now, perhaps it will be harder to retake for discussion later if it appears
as declined?.

--001636eee3dcc0cb9904a3071d92--