Hi!
> Better error messages are obviously better than just replacing the name of
> the token, however this argument is saying that because this isn't perfect
> let's do nothing.
I don't think this is the argument. I think the argument is rather than
half-fix the problem wrong way, let's fully
Hello Andrea, Benjamin, and others,
Better error messages are obviously better than just replacing the name of
the token, however this argument is saying that because this isn't perfect
let's do nothing.
I wasn't aware that Rowan had made good progress on his patch, however, if
this patch needs
On Sat, 27 Jun 2020 at 11:20, Benjamin Eberlei wrote:
> 1. The token name has historic value and should be preserved as such
I don't think it has historic value. It might have nostalgic value but
nostalgia for:
> I think everyone hits it once or twice, has the "wtf?" moment, googles, and
>
> Can anyone working on internals explain why traits don’t allow constants
> (either technically or philosophically)?
> Moreover, what’s the opinion(s) of the list, on adding support for this?
> Would an RFC be needed?
I don't think there's any insurmountable obstacles, but it would be useful
> It’s always struck me as slightly odd that traits don’t support constants the
> way classes and interfaces do.
> I tried to find an explanation of the lack of support in the original RFC,
> and came up empty.
>
> A consequent discussion in R11 has led me here.
> Can anyone working on
Hi Dan Ack,
> Also, I didn't understand why there was a problem with formatting
> traces in userland. I saw a link to some code, but no clear
> description of what the problem was.
I expanded the description of how `getTraceAsString()` might be improperly used
in existing code and moved it to
> >
> > I've created a new RFC
> > https://wiki.php.net/rfc/throwable_string_param_max_len
>
> How come you're proposing an ini setting instead of adding a parameter
> to getTraceAsString() that specifies the length for params?
I don't expect many people to use a parameter for
On Sat, 27 Jun 2020 at 16:16, tyson andre wrote:
>
> I've created a new RFC https://wiki.php.net/rfc/throwable_string_param_max_len
How come you're proposing an ini setting instead of adding a parameter
to getTraceAsString() that specifies the length for params?
Also, I didn't understand why
> On Jun 23, 2020, at 8:30 PM, Larry Garfield wrote:
>
> Greetings, Internalians.
>
> There has been much talk of the \PHP namespace of late, including one
> unsuccessful RFC. In the discussion, the pushback broke down into two main
> camps:
>
> * We should never namespace anything ever.
> On Jun 27, 2020, at 9:52 AM, Stephen Reay wrote:
>
> Hi,
>
> It’s always struck me as slightly odd that traits don’t support constants the
> way classes and interfaces do.
> I tried to find an explanation of the lack of support in the original RFC,
> and came up empty.
>
> A consequent
Hi internals,
I've created a new RFC https://wiki.php.net/rfc/throwable_string_param_max_len
Since 2003, `Throwable->getTraceAsString()` and `Throwable->__toString()`
have limited the length of string function arguments in stringified stack
traces to 15 bytes
(e.g. `#0 /path/to/file.php(line)
On 27/06/2020 10:56, Andrea Faulds wrote:
Of course, if T_PAAMAYIM_NEKUDOTAYIM was never encountered by userland
developers, this RFC wouldn't exist. The thing is, I don't think
T_DOUBLE_COLON should be encountered by userland developers either —
in my view, as an implementation detail, token
Hi again,
A further and perhaps more important thought: I think the token names
are actually the least confusing part of parser errors, even for the
famous T_PAAMAYIM_NEKUDOTAYIM. Changing it to T_DOUBLE_COLON may not
help much, because the parser only tells you what the next token it
Hi,
It’s always struck me as slightly odd that traits don’t support constants the
way classes and interfaces do.
I tried to find an explanation of the lack of support in the original RFC, and
came up empty.
A consequent discussion in R11 has led me here.
Can anyone working on internals explain
On Sat, Jun 27, 2020 at 11:57 AM Andrea Faulds wrote:
> Hi,
>
> G. P. B. wrote:
> > https://wiki.php.net/rfc/rename-double-colon-token
>
> I have voted No to this, and I hope I can convince some others to do the
> same.
>
> T_PAAMAYIM_NEKUDOTAYIM is such a famous token that there is probably
>
On Sat, Jun 27, 2020 at 11:57 AM Andrea Faulds wrote:
> Hi,
>
> G. P. B. wrote:
> > https://wiki.php.net/rfc/rename-double-colon-token
>
> I have voted No to this, and I hope I can convince some others to do the
> same.
>
> T_PAAMAYIM_NEKUDOTAYIM is such a famous token that there is probably
>
Hi,
G. P. B. wrote:
https://wiki.php.net/rfc/rename-double-colon-token
I have voted No to this, and I hope I can convince some others to do the
same.
T_PAAMAYIM_NEKUDOTAYIM is such a famous token that there is probably
nobody in internals who doesn't know what it means, and for new
17 matches
Mail list logo
