Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108945
MIME-Version: 1.0
References: <CAEPJdunSr8PkBtSLO8g_JMLzM4cFVnXsQSEMFmu2RN25XT=grw@mail.gmail.com>
 <CAEPJduncSM_vADKZast=Uvn2d0YN3siuSs8hyP1uk=rhg1g8Tw@mail.gmail.com>
In-Reply-To: <CAEPJduncSM_vADKZast=Uvn2d0YN3siuSs8hyP1uk=rhg1g8Tw@mail.gmail.com>
Date: Tue, 10 Mar 2020 12:58:08 +0100
Message-ID: <CABdc3Wo4TTkz-t24hHQdffQFR07pnwRQ3=d-OU+qc-ue_gcgFg@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ff841f05a07ed569"
Subject: Re: [PHP-DEV] Re: [RFC] Attributes v2
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--000000000000ff841f05a07ed569
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

pon., 9 mar 2020 o 15:45 Benjamin Eberlei <kontakt@beberlei.de> napisa=C5=
=82(a):

> On Mon, Mar 9, 2020 at 3:42 PM Benjamin Eberlei <kontakt@beberlei.de>
> wrote:
>
> > Hi all,
> >
> > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
> > 2016 with a few changes, incorporating feedback from the mailing list
> back
> > then and from talking to previous no voters.
> >
> > The RFC is at https://wiki.php.net/rfc/attributes_v2
> >
> > A working patch is at https://github.com/beberlei/php-src/pull/2 though
> > work around the details is still necessary.
> >
> > The RFC contains a section with common criticism and objections to
> > attributes, and I hope to have collected and responded to a good amount
> > already from previous discussions.
> >
> > There is also a fair amount of implementation detail still up for debat=
e,
> > which is noted in "Open Issues". I have pre-committed to one approach,
> but
> > listed alternatives there. On these issues I am looking for your
> feedback.
> >
>
> Obviously I am looking for feedback on the whole RFC, not just the open
> issues :-)
>
> >
> > greetings
> > Benjamin
> >
>


Hi Benjamin,

I'm really glad you're taking up the baton!

IMHO a bunch of straw polls could provide a way more beneficial knowledge
about feelings
people who can vote up for this feature. What do you think?

It could be good to discover the negative or positive feelings as well as
"I'm not opposite" feelings.

From what I can see now and I didn't think of it earlier are some details
but we should ask the question
how far we wanna go with this feature for its an initial shape.

Are we gonna provide complete attributes feature like C#, Java etc. which
allows for
annotating annotations (whatever it's called for me annotations/attributes
has no difference for now)
meaning they allow to put metadata which puts restrictions on:

1. Usage of the attribute should be allowed once or multiple times
regarding the same target?
2. Targetting attributes should be annotated - no matter if through an
interface or annotation?
3. Allow for inheritance should be annotated - meaning when reading
attributes for class Bar
  which extends Foo on which attributes are set, should I get attributes or
not?
4. Should attributes be resolvable all the time, what if the class won't
exist on runtime?
  In some languages like Java there are for eg. documentary annotations
which live with code but are not stored on runtime.

Or we simply want to provide a simple way of retrieving the metadata from
class/trait/interface/properties/methods/functions without checking their
repeateness, without inheritance,
without validating the targets where they appear, and just allow to move
any kind of attributes into
the language and allow the userland to decide what to do with them and how
to handle them properly?

The thing which I haven't consider earlier and I find it nice features is
the ability
to filter annotations against some abstract/base annotation - it may be
described as a better cause
I do feel like it should be done through extending of the interface and not
by an abstract class.
Like from the RFC itself the `\Validator\Attributes\Attribute::class` it
wouldn't make sense for it to be
a class, not even an abstract class, there's probably no method which this
abstract will provide.

Attributes should be forbidden for instantiation and this if funny cause
they do have a public __construct
so they look like classes but are not actually classes which you should be
allowed to instantiate wherever
you want, right? So we agree it looks a little weird here but dunno if
there's something we can do.

cheers,
Micha=C5=82 Brzuchalski

--000000000000ff841f05a07ed569--