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
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,
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
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
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
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
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
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
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, 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
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 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, 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 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 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 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, 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 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 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 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
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
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 ;-)
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
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 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: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
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, 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
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 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, 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 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, 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: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 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, 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 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,
37 matches
Mail list logo
