[copy of the email that I have accidentally sent to Mark individually]
Hey,
As much as I appreciate your enthusiasm and ideas, adding your name on
my original RFC and editing its contents without my approval is not
acceptable. Especially considering that contents of the RFCs are a
direct
...and introducing 'number' would also be a huge BC break (even in our
codebase there's a class named 'Number').
Best regards,
Benas
On Sun, Nov 8, 2020, 7:26 PM Reindl Harald (privat)
wrote:
>
>
> Am 08.11.20 um 18:09 schrieb Eugene Sidelnyk:
> > Hello, internals!
> >
> > What do you think
On Mon, Oct 19, 2020, 6:17 PM Theodore Brown wrote:
> On Mon, Oct 5, 2020 at 9:24 AM Nicolas Grekas
> wrote:
>
> >> I'm wondering if the syntax that allows for several attributes is
> >> really future-proof when considering nested attributes:
> >>
> >>
> >> *1.*
> >> #[foo]
> >> #[bar]
> >>
>
And why would we want to do that?
On Tue, Sep 22, 2020, 4:04 PM Marco Pivetta wrote:
> Probably easier/simpler to deprecate (then remove) property declaration
> groups, no?
>
> On Tue, Sep 22, 2020, 14:51 Nikita Popov wrote:
>
> > Hi internals,
> >
> > Currently, placing an attribute on
.
>
> On Tue, Sep 15, 2020 at 9:40 AM Benas IML
> wrote:
>
>> Hey,
>>
>> During my free time, I'm implementing that specific `array_keys`
>> optimization. I'm not planning on supporting cases like yours (i. e.
>> indirection through a variable) since there's
Hey,
During my free time, I'm implementing that specific `array_keys`
optimization. I'm not planning on supporting cases like yours (i. e.
indirection through a variable) since there's no point in doing that. And
also, it's not feasible to support every use case. Should we also support
cases like
On Thu, Sep 3, 2020, 7:05 PM Sara Golemon wrote:
> On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues
> wrote:
>
> > Do you think that it could be proxied? I mean, optimize foreach
> > (array_keys()...) syntax to not call array_keys() in fact, but a
> optimized
> > version of foreach to handle key
+1.
I'd also like to mention that other languages don't have any kind of
syntactic sugar/special syntax for iterating over keys. That is achieved
using a function though.
This proposal to me seems a bit like the "return if/guard" RFC i. e. I see
no value in it.
On Wed, Sep 2, 2020, 8:13 PM
On Tue, Aug 18, 2020, 1:42 AM Andreas Leathley wrote:
> On 18.08.20 00:03, Benas IML wrote:
> > And then boo-yah, 6 months later we want to implement a cool new
> > feature to
> > attributes (a lot of examples were said before, ain't repeating myself)
> but
On Tue, Aug 18, 2020, 1:04 AM Jakob Givoni wrote:
> Hi Benas,
>
> On Mon, Aug 17, 2020 at 11:34 PM Benas IML
> wrote:
> >
> > On Tue, Aug 18, 2020, 12:25 AM Jakob Givoni wrote:
> >>
> >> The question is now if it's reasonable at all to change someth
On Tue, Aug 18, 2020, 12:56 AM Jakob Givoni wrote:
> On Sun, Aug 16, 2020 at 11:36 AM Benjamin Eberlei
> wrote:
> >
> > We have updated the RFC with all (hopefully) of the feedback from this
> > discussion:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > Most notable
On Tue, Aug 18, 2020, 12:25 AM Jakob Givoni wrote:
> On Sun, Aug 16, 2020 at 11:32 AM Benjamin Eberlei
> wrote:
> >
> > On Sun, Aug 16, 2020 at 10:39 AM Jakob Givoni wrote:
> >>
> >> Hi Benjamin,
> >>
> >> I'm sorry, but I don't understand your argument.
> >> It's true that annotations used to
On Mon, Aug 17, 2020, 4:07 PM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei
> wrote:
>
> > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> wrote:
> > > However, ending delimiters in PHP have little to do with how "complex"
> > > a syntax construct is (which is a
On Sat, Aug 15, 2020, 2:53 PM Björn Larsson
wrote:
> Den 2020-08-14 kl. 21:23, skrev Derick Rethans:
>
> > On Fri, 14 Aug 2020, Sara Golemon wrote:
> >
> >> Derick was trying to be good and meet my beta3 deadline.
> > And I even got that date wrong by a week. Oops.
> >
> >> Fortunately, I gave
On Mon, Aug 10, 2020, 4:28 PM Theodore Brown wrote:
> On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans wrote:
>
> > I've just opened the vote to make sure we don't make a terrible mistake
> > with using the @@ syntax for attributes:
> >
> >
After sending out the email, I found out that I replied to the wrong email,
nevermind... Sorry about that!
Best regards,
Benas
On Sun, Aug 9, 2020, 8:25 PM Benas IML wrote:
> Hey Chris,
>
> thanks for the RFC but I'd like to remind you that we are already past the
> feature free
Hey Chris,
thanks for the RFC but I'd like to remind you that we are already past the
feature freeze. Moreover, it seems that you don't have an actual
implementation as well.
Best regards,
Benas
On Sun, Aug 9, 2020, 8:15 PM Chris Riley wrote:
> Hi all,
>
> RFC link:
>
>
> This is some new complexity, even if only a small amount right now.
> My question remains about how much more added complexity it will
> require later if we implement extensions like nested attributes.
>
What? Are you actually saying that 30 lines of code add "complexity"? I
think you
Hey Theodore,
On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wrote:
> On Thu, Aug 6, 2020 at 5:24 AM Benas IML
> wrote:
>
> > On Thu, 6 Aug 2020 at 11:45, Rowan Tommins
> wrote:
> >
> > > On Thu, 6 Aug 2020 at 09:12, Benas IML
> wrote:
> > >
> &
15 years old.
Best regards,
Benas
P.S: I accidentally sent this to Rowan only, so forwarding this to the
mailing list as well.
On Thu, 6 Aug 2020 at 11:45, Rowan Tommins wrote:
>
> On Thu, 6 Aug 2020 at 09:12, Benas IML wrote:
>
> >
> > But by sacrificing a few v
On Thu, Aug 6, 2020, 10:18 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
> Derick Rethans a écrit :
> > From the RFC:
> > - No ending delimiter
>
> As said before, it does have an ending delimiter when they are arguments
> since
> there
A little nitpick but I don't think that `@@` really signals familiarity
with docblocks.
Nevertheless, I really like `@[...]`. I think it combines best of the both
worlds (little-to-no BC breaks, ending delimiter, etc.) and also looks
aesthetically pleasing.
Best regards,
Benas
On Tue, Aug 4,
`@@NoJit` sounds pretty alright to me.
On Mon, Aug 3, 2020, 11:27 PM Derick Rethans wrote:
> On 3 August 2020 20:20:35 BST, Benjamin Eberlei
> wrote:
>
> >In that case maybe we should rename the attribute to @@DisableJit ?
> >This
> >would not clutter the global namespace with a "jit" class.
>
Just to chime in, `<<...>>` does not have any BC implications or problems
with bit shift operators.
On Thu, Jul 23, 2020, 6:05 PM Marcio Almada wrote:
> Hi
>
> > On Thu, July 23 2020 at 1:26 AM Mark Randall wrote:
> >
> > > On 23/07/2020 02:00, Sara Golemon wrote:
> > > > Regards the vote; I
Hey internals,
I have closed the vote. The RFC was declined with 34 in favor and 22
against.
Best regards,
Benas
On Fri, Jul 3, 2020, 12:12 AM Benas IML wrote:
> Hey internals,
>
> I have opened the voting for the RFC, let's hope everything is going
> to be smooth :). If you ha
Also, +1. I don't really care whether we switch back to `<<...>>` or
`#[...]` but I think `@@` was a bad choice and thus, I think it would be a
much more sensible decision to change the syntax again. At least for the
sake of not running into new ambiguities and in order to stay more similar
with
Hey Michał,
Personally, I think instead of making `declare(strict_types=1);` to look
more like a constant, we should make it look more like a function.
Since it seems that the named parameters RFC is going to be accepted, I
think allowing for alternative `declare(strict_types: 1);` syntax would
r_ret_void
Best regards,
Benas
On Fri, 3 Jul 2020 at 00:12, Benas IML wrote:
>
> Hey internals,
>
> I have opened the voting for the RFC, let's hope everything is going
> to be smooth :). If you have any other questions, let me know!
>
> RFC: https://wiki.php.net/rfc/make
Jul 2020 at 00:12, Benas IML wrote:
>
> Hey internals,
>
> I have opened the voting for the RFC, let's hope everything is going
> to be smooth :). If you have any other questions, let me know!
>
> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
>
> Best regards,
Hey internals,
I closed the vote and will be restarting it tomorrow since the
secondary vote breaks the policy (no BC breaks in minor versions).
I will update the RFC and open it tomorrow (July 4th) again.
Best regards,
Benas Seliuginas
--
PHP Internals - PHP Runtime Development Mailing List
Hey Theodore,
On Fri, 3 Jul 2020 at 19:52, Theodore Brown wrote:
>
> On Thu, July 2, 2020 at 4:12 PM Benas IML wrote:
>
> > I have opened the voting for the RFC, let's hope everything is going
> > to be smooth :). If you have any other questions, let me know!
> >
&g
*just let me know if that is a minor change and I'm okay with updating the
RFC right now.
Best regards,
Benas Seliuginas
On Fri, Jul 3, 2020, 6:20 PM Benas IML wrote:
> Hey Zeev,
>
> For me it doesn't really matter if we enforce `void` rules implicitly in
> PHP 8.1 or PHP 9.0. Jus
Hey Zeev,
For me it doesn't really matter if we enforce `void` rules implicitly in
PHP 8.1 or PHP 9.0. Just that we do at some point.
Thus, I'm okay with closing the secondary vote and updating the RFC to
mention only PHP 9.0 (and not PHP 8.1).
Best regards,
Benas Seliuginas
On Fri, Jul 3,
destruct(). As people
> shouldn't have done this, IMO it is a smaller BC issue than the BC break
> that would have been caused if the proposed #[] attribute syntax had been
> chosen.
>
> Peter
>
> On Thu, 2 Jul 2020 at 22:12, Benas IML wrote:
>
>> Hey internals,
>>
>&
>
> I think that Larry's and Rowan's replies on the original discussion thread
>> really well explained as to why it makes sense to allow an explicit `void`
>> return type, so I'll just quote them instead ;)
>>
>> Larry:
>> > I see this in the same category as __toString().
>>
>
> I read those
, is there any particular reason you voted no? If there are any
questions, let me know.
Best regards,
Benas Seliuginas
On Fri, Jul 3, 2020, 12:04 PM Benjamin Eberlei wrote:
>
>
> On Thu, Jul 2, 2020 at 11:12 PM Benas IML
> wrote:
>
>> Hey internals,
>>
>> I have opened t
Hey Nicolas,
Hey internals,
>>
>> I have opened the voting for the RFC, let's hope everything is going
>> to be smooth :). If you have any other questions, let me know!
>>
>> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
>>
>
> Hi Benas,
>
> I voted "no" to the RFC because to me adding "void"
Hey internals,
I have opened the voting for the RFC, let's hope everything is going
to be smooth :). If you have any other questions, let me know!
RFC: https://wiki.php.net/rfc/make_ctor_ret_void
Best regards,
Benas Seliuginas
--
PHP Internals - PHP Runtime Development Mailing List
To
Since 2 weeks have passed and there wasn't much discussion, I would like to
remind that I'm opening the vote on Friday (July 3rd).
Best regards,
Benas Seliuginas
On Wed, Jun 17, 2020, 2:10 AM Benas IML wrote:
> Hey internals,
>
> This is a completely refined, follow-up RFC to my ori
Hey internals,
Is there any particular reason as to why constants cannot be typed? For example:
```
class Test {
// this is illegal
public const int TEST = 1;
}
```
Having typed constants would be quite beneficial. First of all, we
would obviously be more consistent with
Hey,
On Tue, Jun 23, 2020, 11:34 AM Ilija Tovilo wrote:
> Hi Benas
>
> >> I'd like to announce the match expression v2 RFC:
> >> https://wiki.php.net/rfc/match_expression_v2
>
> > Then it's not a standalone expression but a block. In this case, you
> cannot add an optional semicolon at all.
> >
On Tue, Jun 23, 2020, 11:23 AM Björn Larsson
wrote:
> Den 2020-06-22 kl. 18:05, skrev Benas IML:
>
> > On Mon, Jun 22, 2020, 6:35 PM Björn Larsson
> > wrote:
> >
> >> Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo:
> >>
> >>>
On Mon, Jun 22, 2020, 6:35 PM Björn Larsson
wrote:
> Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo:
>
> > Hi Björn
> >
> >>> I'd like to announce the match expression v2 RFC:
> >>> https://wiki.php.net/rfc/match_expression_v2
> >> Well one could argue that when working with legacy code
Hey Nikita,
This is a bit late response but ah, who cares ;-)
I suppose that for consistency with named params, we should also make `declare`
compatible with this syntax. So for example, `declare(strict_types:
1);` would be
the same as `declare(strict_types=1)`. This would also make much more
Best regards,
Benas
On Thu, Jun 18, 2020, 11:49 PM Andreas Hennings wrote:
>
>
> On Thu, 18 Jun 2020 at 22:29, Benas IML wrote:
>
>> Hey Andreas,
>>
>> It seems that you actually haven't read my reply carefully enough.
>>
>> > But this distinction w
ople will make arbitrary choices and
argue about it, or look for a convention.
Already addressed this.
Best regards,
Benas
On Thu, Jun 18, 2020, 11:15 PM Andreas Hennings wrote:
>
> On Thu, 18 Jun 2020 at 18:33, Benas IML wrote:
>
>> Hey Andreas,
>>
>> That is inco
understand that you were
responding to email and I'm thankful for that :)
Best regards,
Benas
On Thu, Jun 18, 2020, 7:43 PM Bob Weinand wrote:
> Hey,
>
> Am 18.06.2020 um 17:18 schrieb Benas IML :
>
> Hey Bob,
>
> Magic methods are **never** supposed to be calle
ak it is?
>
> Also, a suggestion on how to fix the BC issue if it exists could be
> mentioned I guess.
>
> Thank you,
> Aled
>
> On Wed, Jun 17, 2020, 02:11 Benas IML wrote:
>
>> Hey internals,
>>
>> This is a completely refined, follow-up RFC to my ori
declaration on constructors.
>
> I am ok with restricting the use of "return *;" inside a constructor.
> But I don't like allowing the ": void" declaration.
>
> Greetings
>
> On Thu, 18 Jun 2020 at 17:18, Benas IML wrote:
>
>> Hey Bob,
>
gards,
Benas
On Thu, Jun 18, 2020, 4:06 PM Bob Weinand wrote:
> > Am 17.06.2020 um 01:10 schrieb Benas IML :
> >
> > Hey internals,
> >
> > This is a completely refined, follow-up RFC to my original RFC. Based on
> the
> > feedback I have received, this
l BC break (given that there
will be a deprecation warning in PHP 8.0), should we start enforcing `void`
rules on constructors and destructors in PHP 8.1 or PHP 9.0?
Best regards,
Benas
On Wed, Jun 17, 2020, 2:10 AM Benas IML wrote:
> Hey internals,
>
> This is a completely refined,
. Additionally, to allow declaring an
explicit `: void` return type on constructors/destructors.
Best regards,
Benas
On Tue, 16 Jun 2020 at 03:34, Benas IML wrote:
>
> Hey internals,
>
> I am proposing to allow void return type for constructors/destructors. Note,
> that this i
020 um 13:59 schrieb Benas IML :
> > We should allow newer codebases to enforce `void` rules on
> > constructors/destructors by allowing to explicitly declare return type as
> > `void`.
>
> I don't see a big benefit in this explicit return type void as newer
> codebases hopef
Thanks everybody for the replies.
> However, I am also fine if the void return value is only enforced when the
> void return
> type is declared. Additionally, we could emit a deprecation notice/warning
> when
> there is no return type declaration, but a value is returned. I think this
> would
Hey internals,
This is a completely refined, follow-up RFC to my original RFC. Based on the
feedback I have received, this PR implements full validation and implicitly
enforces `void` rules on constructors/destructors while also allowing to
declare an **optional** explicit `void` return type.
feature, so let me know!
This PR should also address all of Máté's concerns since it makes
constructors and destructors always return `void` (even when no explicit
`void` return type is specified).
Best regards,
Benas Seliuginas
On Tue, Jun 16, 2020, 3:34 AM Benas IML wrote:
> Hey intern
to).
It seems that I will have to rewrite the BC section to be more clear on
that.
Best regards,
Benas
On Tue, Jun 16, 2020, 5:36 PM Christoph M. Becker wrote:
> On 16.06.2020 at 16:19, Benas IML wrote:
>
> > I meant something like this:
> > ```
> > > class Test {
> >
.P.B. wrote:
>> > Seems like a no brainer and a good addition. :)
>>
>> For situations where stuff is simple, 'no brainers' are okay.
>> For situations where everything is horribly convoluted, 'no brainers'
>> are often bad.
>>
>> Benas IML wrote:
>>
meant something like this:
```
wrote:
> G.P.B. wrote:
> > Seems like a no brainer and a good addition. :)
>
> For situations where stuff is simple, 'no brainers' are okay.
> For situations where everything is horribly convoluted, 'no brainers'
> are often bad.
>
> Benas IML
Hey Máté,
On Tue, Jun 16, 2020, 11:31 AM Máté Kocsis wrote:
> Hi Benas,
> Overall, I'm very much in favour of disallowing returning a value from
constructors.
> However, I think the RFC should deal with the return value and the
signature validation
> in the same time, so that we can vote about
Hey internals,
I am proposing to allow void return type for constructors/destructors. Note,
that this is an **optional** and cosmetic-only addition! All of the
reasoning
is in the RFC.
RFC: https://wiki.php.net/rfc/constructor_return_type
Best regards,
Benas
+1
On Tue, Jun 9, 2020, 2:56 PM Benjamin Eberlei wrote:
> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown
> wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback
Hey,
I'm not sure what you're referring to as "generic variable system" but
given that you mentioned "type", I assume you mean typed variables? If so,
PHP is never going to have typed variables due to performance implications.
As for the `/**` and `*/`, I believe Marco was talking about Doctrine
Thank you for the update! Given that there is still an open issue, is the
RFC proposing flags or a separate `<>` attribute?
Best regards,
Benas
On Thu, Jun 4, 2020, 12:29 PM Benjamin Eberlei wrote:
> I have changed back the rename from namespacing to Attributes\Attribute to
> using just
Hey!
That's why I am against this RFC or any other "change style to what I
prefer". PHP's current attribute syntax is consistent with other languages
and poses no BC breaks whatsoever.
Best regards,
Benas
On Thu, Jun 4, 2020, 1:37 PM Ilija Tovilo wrote:
> > > Does the PHP parser prevent us
Hello,
yes, that would create ambiguity in the parser since `#` (just like `//`)
is for comments.
Best regards,
Benas
On Thu, Jun 4, 2020, 11:03 AM Peter Bowyer
wrote:
> Hi Theodore,
>
> On Thu, 4 Jun 2020 at 00:55, Theodore Brown
> wrote:
>
> >
Hello,
thank you for the RFC but I hope it doesn't pass. Here's my constructive
feedback as to why.
Verbosity? Are we really debating whether adding 2 extra characters is more
"verbose"? Well, with 3 or more grouped attributes, we are less verbose by 1
character. I don't find "verbosity" to be
Hey,
Here's a quote from Ben Ramsey that basically sums up the problem:
> This appears to be happening due to DMARC rules on the domains of the
senders.
> I had the same thing happen to my emails, so I had to relax my DMARC
rules. If
> your rules are set too strict, servers see the From address
It seems that the RFC was updated to use the `Attributes` namespace. I
think this is a bad idea since we're reserving a generic namespace that we
haven't even "soft" reserved. Also, the loss of fallback to global
namespace is a turning point for me.
Generally, I think we should instead do
Hey,
yes, there are no traits at the moment. Also, in PHP 8 there was `WeakMap`
class added to the core as well.
Best regards,
Benas Seliuginas
P.S: your email is marked as spam for me and probably for everyone else
too, so
most of the internals probably missed your emails. Try using a
That's a brilliant idea, completely agreed, Rowan!
On the other note, don't want to nitpick here but I believe that it would be
better to name the repeatable attribute simply as `<>`. It would
match other languages (such as Java) and the naming wouldn't be that
verbose.
Also IMO, I think for
Agreed.
I don't think we should pollute any other than the `PHP\` namespace. If
that RFC doesn't pass though, we should keep the `Attribute` class in the
global namespace.
Global namespace is already reserved for PHP and so, BC breaks aren't that
severe whereas `Attributes\` namespace isn't
Hello,
Would it possible to make a separate RFC for renaming `PhpAttribute` to
`Attribute` and `PhpCompilerAttribute` to `CompilerAttribute`? Since it
would a huge BC break changing this in PHP 8.1.
Best regards,
Benas Seliuginas
Hey,
I personally think that `UserlandAttribute` is too verbose and a quite
useless change since just using `Attribute` will make little to no BC
compatibility breaks (we know that thanks to Rowan, please check out
Renaming PhpAttribute thread) and would also sound more natural. This would
also
Hello,
first of all, thank you for the RFC but this is a big no-no for me. Your
arguments as to why it's "okay" to make a BC break doesn't make a lot of sense
given the huge "genericness" of the keyword "guard". Laravel's authentication
system is used across thousands of projects (if not more)
Hello,
Not it's not and will likely never be so using `guard` is a really bad idea.
Best regaeds,
Benas Seliuginas
Update: I confused myself reading the RFC, sorry! Everything is alright in
the examples.
>
Hello,
Thank you for your RFC. It seems that your Attribute examples are not
promoted. I suppose that shouldn't be the case?
Best regards,
Benas Seliuginas
Hey,
`guard` would be a keyword this means that all of the classes, interfaces
and traits named Guard would be illegal. Therefore Laravel's `Guard`
interface would be incompatible with PHP 8 which in turn means thousands of
web applications would be too.
Best regards,
Benas Seliuginas
Hello,
I think that we SHOULD not introduce a new keyword (e. g. guard) since that
would be a "major major" backwards incompatibility. "Guard" is a really
generic
word and a great example of that is Laravel and their authentication guards.
In general, I don't think that early returns require a
Hello,
Is there any update on the RFC? Given that there isn't much discussion and 2
weeks have passed, I believe it's safe to move this into a voting phase.
Best regards,
Benas Seliuginas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I would actually go as far as to say that this is going to be PHP 8
signature
feature.
Best regards,
Benas Seliuginas
Hello,
You should ask Benjamin this question as he is the Attributes RFC author.
>From my standpoint, I don't really believe we can remove it. As without it,
any class would be considered as an attribute - even one that isn't
supposed to be.
Best regards,
Ben.
Hello,
> Again, your assumption that just about everyone uses namespaced classes
> doesn't take into account closed source projects. I don't care if it's a
major
> release or not - BC breaks should always be avoided without a major
benefit
With an introduction of any new language construct,
Hello,
Since your project is just a single example, we still can't make such a bold
claim that `\Attribute` is used a lot.
While "attribute" is a fairly generic word, just about everyone uses
namespaced
classes and therefore it's not a huge problem. Moreover, PHP 8 is a major
release so BC in
Hey internals,
Since this is just an implementation detail, Benjamin will submit a new PR
himself (after merging Attributes v2 into PHP) to rename `PhpAttribute`. As
such, I am not making a separate RFC.
Best regards,
Benas Seliuginas.
--
PHP Internals - PHP Runtime Development Mailing List
To
Hello, Christoph,
thank you so much!
Best regards,
Benas Seliuginas.
Hey internals,
I need RFC karma for creating and proposing the "Renaming PhpAttribute" RFC.
Account's username: moliata
Best regards,
Benas Seliuginas.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
> Speaking on the other note, is there any problem on my side but it doesn't
> seem that I am able to register for a PHP wiki account [1]. I keep getting an
> error message "That wasn't the answer we were expecting".
This is no longer a problem, I successfully registered my wiki account.
Hey,
> Like many other things in life, just because you don't see something doesn't
> mean that it is certainly not there ;-)
I do understand your point and I do agree that there may be some minimal
collision but stating that `Attribute` is too generic and will needlessly
collide with code in
Hello,
> `Attribute` is certainly too generic, and will needlessly collide with code
> in the wild.
Could you provide any examples as to where '\Attribute' is being used in the
wild? I haven't seen a single project that has an Attribute class and uses the
global namespace.
> I suggest circling
Hey internals,
Since it's safe to say that the Attributes v2 RFC has passed, I wanted to
make a separate thread based on the comment by Rowan Tommins in the PHP
namespace policy thread. This is a quote from his comment:
> One prefix doesn't make a trend. "PhpToken" is a different case - it's a
>
93 matches
Mail list logo
