On Tue, Aug 11, 2020, at 11:54 AM, Theodore Brown wrote:
> On Tue, Aug 11, 2020 at 11:36 AM Rowan Tommins
> wrote:
> What will you grep for if you want to find all places where the Route
> attribute is used (but not some other class named Route)?
I'd go to the Route attribute class in my IDE,
On Tue, 11 Aug 2020 at 17:54, Theodore Brown wrote:
>
> I think you may have misunderstood my point - it's not so much about
> the leading symbols but about grouping.
That sounds like a reason to vote No to grouping, which you already did:
https://wiki.php.net/rfc/attribute_amendments#group_st
On 11.08.20 18:38, Sara Golemon wrote:
The perf penalty on 7 and earlier would probably be similar to existing
state of the world.
Parsing a docblock is easier to fetch from the runtime (as we actually
store it), but docblocks contain more than just annotations, so some plus
some minus.
PHP 8+ pe
On Tue, Aug 11, 2020 at 11:36 AM Rowan Tommins wrote:
> On Tue, 11 Aug 2020 at 17:07, Theodore Brown wrote:
>
> > > > fact that the @@ syntax makes attributes easier to grep for.
> >
> > This can be a simple Yes or No. With @@ or @: you can type those
> > symbols followed by the attribute name
On Tue, Aug 11, 2020 at 11:38 AM Sara Golemon wrote:
> PHP 8+ performance on theses would certainly be between though, and that's
> an extra carrot to push users to upgrade. If annotations can't be written
> until after users upgrade, then that carrot vanishes.
>
*PHP 8+ performance on these wo
On Tue, Aug 11, 2020 at 11:25 AM Andreas Leathley
wrote:
> This would be a feature if libraries start parsing PHP token by token
> and start supporting the #[] syntax for the 7.x versions of PHP - then
> early adoption would be possible and it would be a real feature. But it
> seems unclear if th
On Tue, 11 Aug 2020 at 17:07, Theodore Brown wrote:
>
> I would suggest "Kinds of symbols used".
>
> @@ is easier since it only uses one kind of symbol, rather than
> switching between two or three symbols which are often on different
> sides of the keyboard.
>
Honestly, this feels about as obj
On 11.08.20 18:07, Sara Golemon wrote:
Writing this on PHP 7 (or any earlier version for that matter) would be
valid syntax (ignored as a comment):
#[SomeAttr(123)]
function someFunc() {}
That's what's meant by Forward Compatibility. Library/Framework authors
could aggressively adopt attribute
On Tue, Aug 11, 2020 at 10:07 AM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> I'd like to explain my rationale. Most of the time I end up using
> "#[todo] Whatever" while documenting my code... my intentions are "#
> [todo] ...", but you know... missing that space char doesn't b
On Tue, Aug 11, 2020 at 10:39 AM Rowan Tommins wrote:
> On Tue, 11 Aug 2020 at 16:31, Theodore Brown wrote:
>
> > Anyway, please do add easy typeability to the matrix
>
> How would you measure "easy typability"? On what keyboard layout?
> Would you write "Yes" and "No", or "quite easy", or mar
Hi,
On 11/08/2020 12:10, Chris Riley wrote:
> What is the expected behaviour of:
>
> @[Bar()];
> class Foo {}
>
> That would appear to be valid code and for the difference of a single ;
> does wildly different things, assuming there is a function Bar defined
> somewhere. (and only by the fact th
On Tue, 11 Aug 2020 at 16:31, Theodore Brown wrote:
>
> How does @@ come out worse?
Seems clear enough to me:
> Additionally, on a US English/US International keybaord, Shift-2 (for @)
> is an awkward combination to type with the pinky and middle finger of
> your left hand.
(Note that this i
> On Aug 11, 2020, at 09:54, Sara Golemon wrote:
>
> On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans wrote:
>
>> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
>>
>>
> Just chiming in to say all, y'all voting for @[...] are making a terrible
> choice, and are you sure you're
On Tue, 11 Aug 2020 at 16:07, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> I'd like to explain my rationale. Most of the time I end up using
> "#[todo] Whatever" while documenting my code... my intentions are "#
> [todo] ...", but you know... missing that space char doesn't brea
On Tue, Aug 11, 2020 at 8:37 AM Derick Rethans wrote:
> On Tue, 11 Aug 2020, Theodore Brown wrote:
>
> > A second downside of @[] that doesn't appear to have been discussed
> > yet is typability. On my keyboard, it requires four different keys on
> > different sides of the keyboard, whereas @@ j
Hi Michael,
On 11/08/2020 12:39, Dan Ackroyd wrote:
> Changing a function to have surprising behaviour just to avoid using a
> different function, that is already available, is a really bad
> tradeoff.
I agree.
function mysleep(float $s): void {
usleep($s * 100);
}
You're welcome ;-)
Hi Sara,
I'd like to explain my rationale. Most of the time I end up using
"#[todo] Whatever" while documenting my code... my intentions are "#
[todo] ...", but you know... missing that space char doesn't break
anything today...
In any case, BC is broken and FC would also not work. Now I assume
it
On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans wrote:
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
>
>
Just chiming in to say all, y'all voting for @[...] are making a terrible
choice, and are you sure you're okay with it?
We have options with varying degrees of backward com
On Tue, 11 Aug 2020 at 14:15, Peter Bowyer
wrote:
> Anyone?
>
> Why is the discussion fixated on [] rather than ()?
>
Elsewhere, Derick clarified that he sees a "conceptual/logical" difference
between brackets around just the argument list and the brackets around the
whole expression, rather th
On 11.08.20 15:15, Lynn wrote:
If typability really matters, we should've deprecated the backtick
version
to run things. We also seem to forget about readability. @@ makes things
really hard to read for me as it draws attention, the same goes for <>
being written as such, with spaces it's fine. I
On Tue, 11 Aug 2020, Theodore Brown wrote:
> A second downside of @[] that doesn't appear to have been discussed
> yet is typability. On my keyboard, it requires four different keys on
> different sides of the keyboard, whereas @@ just requires two keys.
They're the same on a US English/US Inte
On Tue, 11 Aug 2020 at 14:16, Lynn wrote:
> In terms of @[] typability, my IDE auto completes the ] when I type [.
>
I really, really, hate when editors and IDEs do that, and switch off every
variant of it I can find in the settings. Either it will get it wrong
because I'm editing code not writ
On Tue, Aug 11, 2020 at 3:03 PM Theodore Brown
wrote:
> A second downside of @[] that doesn't appear to have been discussed
> yet is typability. On my keyboard, it requires four different keys
> on different sides of the keyboard, whereas @@ just requires two keys.
>
If typability really matters
On Mon, 10 Aug 2020 at 15:41, Peter Bowyer
wrote:
>
>
> On Mon, 10 Aug 2020 at 14:59, Derick Rethans wrote:
>
>> I did answer that as a reply to Rowan:
>>
>> https://externals.io/message/111312#111346
>
>
> I'm with Rowan's response to you:
> https://externals.io/message/111312#111354
>
> What i
On Tue, Aug 11, 2020 at 7:26 AM Chris Riley wrote:
> On Tue, 11 Aug 2020 at 13:21, Derick Rethans wrote:
>
> > On Tue, 11 Aug 2020, Chris Riley wrote:
> >
> > > Quick question.
> > >
> > > What is the expected behaviour of:
> > >
> > > @[Bar()];
> > > class Foo {}
> >
> > That will error out in
On 11.08.2020 at 10:53, Rowan Tommins wrote:
> Unless there are problems with the implementation, this seems like a
> straight-forward win.
Not necessarily a problem, but it has to be considered that POSIX
mandates that nanosleep() shall fail, if "the rqtp argument specified a
nanosecond value […
On Tue, 11 Aug 2020 at 13:21, Derick Rethans wrote:
> On Tue, 11 Aug 2020, Chris Riley wrote:
>
> > Quick question.
> >
> > What is the expected behaviour of:
> >
> > @[Bar()];
> > class Foo {}
>
> That will error out in PHP 8, with:
>
> Parse error: syntax error, unexpected token ";" in Standard
On Tue, 11 Aug 2020, Chris Riley wrote:
> Quick question.
>
> What is the expected behaviour of:
>
> @[Bar()];
> class Foo {}
That will error out in PHP 8, with:
Parse error: syntax error, unexpected token ";" in Standard input code on line 2
cheers,
Derick
--
PHP 7.4 Release Manager
Host o
Björn Larsson wrote:
> Given this unexpected behaviour, one could almost see it as a bug.
This isn't a suddenly noticed new bug. That code has worked like that
since the sleep function was committed twenty-two years ago or for
five years since the release of PHP 7 and the weak/strict RFC
continued
On Tue, 11 Aug 2020 at 12:40, Matteo Beccati wrote:
> Hi,
>
> On 11/08/2020 12:10, Chris Riley wrote:
> > What is the expected behaviour of:
> >
> > @[Bar()];
> > class Foo {}
> >
> > That would appear to be valid code and for the difference of a single ;
> > does wildly different things, assumin
On Tue, 11 Aug 2020 at 13:03, Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
> > Another reason is that sleep(0.1); is silently accepted now (even with
> strict types enabled),
> >
> > That appears to not be true: https://3v4l.org/7YbqX
>
> corrected, should be "without strict types ena
Another reason is that sleep(0.1); is silently accepted now (even with strict types enabled),
That appears to not be true: https://3v4l.org/7YbqX
corrected, should be "without strict types enabled" -
https://3v4l.org/A2olN
"even with strict type enabled" statement in BC section remains valid
Den 2020-08-11 kl. 10:53, skrev Rowan Tommins:
On Tue, 11 Aug 2020 at 08:31, Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
I am the author of https://github.com/php/php-src/pull/5961 , please
provide feedback.
This idea makes a lot of sense to me as a user (I'll leave comments o
Michael Voříšek wrote:
> Another reason is that sleep(0.1); is silently accepted now (even with
strict types enabled),
That appears to not be true: https://3v4l.org/7YbqX
Rowan wrote:
> Unless there are problems with the implementation, this seems like a
straight-forward win.
>From the PR.
> Im
Hi,
Quick question.
What is the expected behaviour of:
@[Bar()];
class Foo {}
That would appear to be valid code and for the difference of a single ;
does wildly different things, assuming there is a function Bar defined
somewhere. (and only by the fact that @ doesn't suppress fatal errors does
On Tue, 11 Aug 2020 at 08:31, Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
> I am the author of https://github.com/php/php-src/pull/5961 , please
> provide feedback.
>
This idea makes a lot of sense to me as a user (I'll leave comments on the
implementation to those with more C expe
Hi everyone,
I am the author of https://github.com/php/php-src/pull/5961 , please
provide feedback.
All details should be in the description, also, please advise if we can
consider it as a small change not requiring RFC as Nikita proposed in
his comment.
With kind regards / Mit freundliche
37 matches
Mail list logo
