> On Wed, May 02, 2019 at 03:00 AM Bishop Bettini
> mailto:bis...@php.net>> wrote:
>
> Great, thanks Tom. Theodore and I are polishing the RFC, then will tackle the
> implementation. Besides the necessary merge fixes, are there any
> changes/improvements you specifically want to make in the new
Hi!
> On Wed, May 01, 2019 at 01:13 AM Bishop Bettini wrote:
> > On Tue, Apr 30, 2019, 19:14 Theodore Brown >
> > On Tue, Apr 30, 2019 at 3:59 PM Bishop Bettini wrote:
> >
> > > Excellent. I hope we can make the case this time. Please
> > > request Wiki karma [1], and we'll iterate on it
Hi!
> On Fri, Apr 26, 2019 at 4:30 PM Theodore Brown wrote:
>
> > On Fri, Apr 26, 2019 at 6:10 AM Rowan Collins
> > wrote:
> >
> > I'm not particularly against this proposal, but I'm not sure how often I'd
> > use it.
>
> How often you use numeric separators depends on what you are doing.
> I
> From: Steven Penny
> Sent: 04 March 2019 15:30
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] print with newline
>
> I think the best option is a new function like "puts" or "posix_puts".
I'm fairly neutral on the feature, but I disagree with this being a function.
It should be a
Hi!
> It seems that the define is backwards though. ‘#define yyparse zendparse’
> still depends on a zendparse symbol. There is no function definition for
> zendparse. All I can see is yyparse in the generated file. What are your
> thoughts?
Right, yyparse is aliased to zendparse. yyparse is
Thank you Peter, Anatol, and Kalle!
> Thomas, please check https://wiki.php.net/vcs/gitworkflow and ask if there's
> something to be cleared out.
Thanks for the link - I'll be sure to ask if there is anything that's not clear.
Regards,
Tom
Hi internals,
I'd like to request for php-src karma for my account (tpunt) in order to help
with the handling of PRs on GitHub. Having been contributing to PHP for
a few years now, I feel like I've got the hang of things well enough to make
more of an impact to the project now.
Thanks,
Tom
Hi!
> Hi,
>
> This mail is going to both the systems group and internals mailing list.
>
> I would like to request a mailing list suspension for the users
> tonymars...@hotmail.com and li...@rhsoft.net, who have recently been
> aggressively derailing the "Scalar Pseudo-type" thread, despite
Hi all,
Voting has now ended, with both votes passing:
- Indenting the closing marker and stripping the whitespace: 24 yes, 5 no
- Removing the trailing newline requirement: 26 yes, 8 no
Thanks to all who participated in the RFC discussion and voting. I will
now make some touch-ups to the
Hi all,
> I would add that this is particularly important on an RFC with two or more
> votes. On most RFCs, the voting question is implied to be "accept the
> change/feature as described above", but as soon as you have two votes, it's
> important to be clear which parts of the proposal are
Hi internals!
Voting has now started on the flexible heredoc and nowdoc syntaxes RFC[1].
Voting will be open for 2 weeks (until November 15th).
Thanks,
Tom
[1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes
Hi Stephen,
> I disagree. To me this change would simply mean that the literal exact
> white-space string preceding the end marker is removed as a prefix from all
> lines.
>
> So if you have an end marker intended by two tab characters, but all the
> ‘content’ lines of the heredoc are indented
Hi,
> If developers accidentally add/subtract leading space from the closing token
> then the whole string changes;
Yes, this is a feature of the chosen semantics. The indentation level of the
body can be chosen based upon the current indentation level of the code (for
which, the closing
Hi Christopher,
> I like the added flexibility in placement of the end token, but I think
> requiring only tabs or spaces, and stripping whitespace from all {here|now}doc
> lines is error prone and adds unnecessary complexity.
I agree that the requirement for using either tabs or spaces is not
Hi Kalle,
> Currently I'm going over every single report to try classify them,
> close reports which would require an RFC, PECL packages with no
> releases for literally years and unassign people from bug reports
> which have not been active (committed) in a long time, or similar.
I did
Morning internals,
I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more
flexible[1]. Any thoughts?
Thanks,
Tom
[1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes
Hi internals!
There doesn't appear to be a status quo on what to do with bug reports targeting
PECL extensions that seem completely unmaintained (i.e. no releases in many
years -
such as bug reports for the SAM extension[1][2]). Would anyone have any
objections
if I closed such reports with
Hi!
> From: m...@kelunik.com>
> I don't like "ArgumentError", how about "WrongArgumentCountError"? Maybe
> also "WrongArgumentsError".
I'd favour simply ArgumentCountError. No need to prepend a "wrong" to theerror
class name - we can already guess it's wrong because it has resulted inan error
Hi!
> From: ocram...@gmail.com
>
> I would say that this makes the entire functional approach:
>
> 1. more readable
> 2. easier to debug (woah, we can haz line numbers for failures!)
>
> Here's the pseudo-code for a typical request/response dispatch cycle:
>
> $request = getGlobals()
> |>
Hi!
> From: dmi...@zend.com
>> On 04/22/2016 02:46 PM, Thomas Punt wrote:
>> Hi Dmitry!
>>
>> Just a couple of comments on this:
>>
>> 1. I'd definitely reuse the php-ast extension for parsing the code into an
>> AST. It performs a number of transfo
Hi Dmitry!
> Hi,
>
>
> I would like to present an RFC proposing support for native annotation.
>
> The naming, syntax and behavior are mostly influenced by HHVM Hack, but not
> exactly the same.
>
> The most interesting difference is an ability to use arbitrary PHP
> expressions as attribute
Hi!
>> Just a quick thought.
>>
>>
>> union Iterable {
>> use array;
>> use ArrayAccess;
>> use Traversable;
>> }
>>
>
> I think this example creates another meaning on the "use" syntax, which
> make "use" context depended.
>
> The "use" statement is already used to "create an class name alias in
Hi Dmitry,
> Java is going to add "var" (http://openjdk.java.net/jeps/286), we are going
> to remove...
We're not going to remove the "var" keyword, just deprecate its usage in
the context of setting properties as public. The "var" keyword will still
remain a reserved word, and it can therefore
Hi!
> Hello all,
>
> I have completed my initial draft of the RFC to deprecate "var" in favor of
> "public": https://wiki.php.net/rfc/var_deprecation
>
> I would greatly appreciate any feedback on this RFC, especially with the
> following:
>
> - Ensuring that all major arguments for & against
Hi!
> I do have a general question about these types of changes: if the
> deprecation were to land in 7.1, when would the actual removal take place -
> 7.2 or 8.0? Or would that be a voting option?
It would have to be done in 8.0, since removing it would constitute a BC break.
It's worth noting
Hi internals!
> Voting has opened for the inclusion of a digit separator in PHP[1]. Voting
> ends in
> one week's time on January 20th.
Voting has now ended with 20 for and 18 against. This means the RFC has been
declined.
Thank you to all who participated in the RFC discussion and voting!
Hi Björn,
> Well, if I had a vote it would definetly be +1. A small question
> though, why is the voting period only one week (small RFC or)?
The RFC is quite simple and short, so I thought a one week voting period would
suffice. I'm more than happy to extend this though if people don't think
Hi internals!
Voting has opened for the inclusion of a digit separator in PHP[1]. Voting ends
in
one week's time on January 20th.
Thanks,
Tom
[1]: http://wiki.php.net/rfc/number_format_separator
--
PHP Internals - PHP Runtime Development Mailing List
To
> Hi internals!
>
> I'd like to propose for the inclusion of a digit separator in PHP. This will
> help to promote the readability of numerical literals in code by enabling for
> the underscore character to be used in between digits.
>
> RFC: https://wiki.php.net/rfc/number_format_separator
> PR:
Hi Christoph,
> echo 1_000;
> will print
> 1000
>
> I think it is important to explicitly note that in the RFC.
>
> With regard to "stringy numerics": besides the potential BC break, IMHO
> there is no need to support digit separators for string literals at all,
> because that could easily be
Hi internals!
I'd like to propose for the inclusion of a digit separator in PHP. This will
help to promote the readability of numerical literals in code by enabling for
the underscore character to be used in between digits.
RFC: https://wiki.php.net/rfc/number_format_separator
PR:
Hi Bob,
> I had this RFC in draft since some time, but delayed it due to all the
> ongoing PHP 7 discussions. Also we have no master branch to merge features in
> until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be
> the
Hey,
I have a question: is there any reason to throw an exception from
__toString, *other* than a non-recoverable error, which would denote that
the object, which the __toString method is called on, does not have any
meaningful string representation? Because if not, core implementation fully
Hey,
Imho TypeException may not be best name for
it, as it's also thrown for non-type related error conditions, like
mismatched argument count.
Would SignatureException be a more apt name for these error conditions?
-Tom
--
PHP Internals - PHP Runtime
Hey Internals,
I'd like to put the variadic empty() RFC to vote.
RFC: https://wiki.php.net/rfc/variadic_empty
Voting will finish in 14 days time on March 21st.
Voting has now ended with a 26:26 yes/no split. This means the RFC has
has been declined (namely surrounding the ambiguity of what
Hey Pavel,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
Result: catchable fatal error
Reason: invocation context is in strict mode
// c.php
?php
Hey David,
A library written in weak or strict mode will have no bearing on its public
API.
Strictly speaking (pun intended), this is not true. A library can easily expose
a
facade that enforces a user of that library (who is in weak mode) to have to
write
in strict mode [1]. Once more, this
Hey,
This is a bug in the library. It declares strict mode but passes a value it
does not know to be an integer to a method requiring an integer. It can
be fixed by simply adding an int type declaration to the constructor or
test method.
The second example is certainly a programmer error,
No, your example would blow up regardless of the caller being in strict mode
or weak mode.
That was the point in my hypothetical example - the library can decide
what mode it wants the user to use (strict or weak) if it wants to.
-Tom
--
PHP Internals -
Hey PHP Internals,
So there hasn't been much discussion on this RFC, and yet a lot of people have
voted -1 on it. This is a little disappointing because I'm not entirely sure why
people are against it - and no one seems to want to debate it either.
From pre-RFC discussions, two main concerns
Hey Dan,
The falsy semantics of empty() means that inlining its behaviour to exactly
match
isset() isn't logical.
The problem isn't so much that the behaviour doesn't match some other
pattern in PHP; the problem is that the function doesn't do what its
name says it does.
if any
Hey Derick,
IMO, because it's not obvious whether it is *all* empty, or *atleast
one* empty. The same argument we had before, when we expanded isset() to
be variadic. We had the same discussion then, resulting on keeping
empty() as it is.
One discussion 11 years ago:
Hello PHP Internals!
I'd like to put the variadic empty() RFC to vote.
RFC: https://wiki.php.net/rfc/variadic_empty
Voting will finish in 14 days time on March 21st.
Thanks,
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hey Zeev,
Another change being considered and not yet in the RFC is re-allowing
leading and trailing spaces for numeric strings (sorry Paddy.)
I think that rejecting leading and trailing spaces for stringy ints is for the
best.
If I only want to accept an integer (in either int or string
Hey Dan,
Making it easier to write bad (imo) code does
not seem a good reason for a change.
The point of this language feature isn't to promote or simplify the creation of
bad code. Developers can (and will) misuse any feature to write poor code.
The aim of this RFC is to enable developers
Hey Markus,
From the RFC:
This behaviour seems to be the most prevalent usage of multiple empty
checks in a condition, therefore benefitting the most end users.
Here I disagree.
I would have assumed from the start that empty() would only return true
if *all* of the entries are
// Sorry, having email formatting problems still. Hopefully this one will be
more legible.
Hey Markus,
From the RFC:
This behaviour seems to be the most prevalent usage of multiple empty
checks in a condition, therefore benefitting the most end users.
Here I disagree.
I would have
Hey Leigh,
Hey Tom,
Patch looks solid (basically the same as the isset logic with OR
instead of AND). I think it's fairly sane to have this feature because
it compliments isset functionality (although I dislike empty
personally - consistency is nice)
No RFC would be complete without a
Hello Internals!
The following RFC aims to make empty() have a variable arity:
https://wiki.php.net/rfc/variadic_empty. This is a simple feature that enables
for a short-hand notation of checking multiple expressions for emptiness (which
is a pretty common thing to do).
I have avoided including
Hi,
From: a...@ajf.me
* I assume Thomas actually meant “where if any arguments passed in are
considered empty, then *true* is returned”, i.e. (empty($a) || empty($b) ||
empty($c))
Sorry for the confusion.
I think the || behaviour is the most useful, as it’s the analogue of isset’s.
Hi Francois,
From: franc...@tekwire.net
May I suggest to extend your proposal to is_null() with the same logic ?
If we were to do the same with is_null(), then would it not be best to do it
with all the is_*() functions? I would be more than happy to cater for those
functions as well, though
Hi,
Date: Fri, 13 Feb 2015 15:09:16 +0100
From: sbj.ml.r...@gmail.com
While I don't know how common such a usage is I'm certain that there
is a use case for it. However, just modifying a subset of the is_*
functions sounds like a bad idea. If such a change is applied it
should be done to
Hi Reeze,
From: re...@php.net
For example: echo $a, $b, $c, empty($a, $b, $c), they are treated equal,
if the empty() means if any one of them is empty then result is TRUE, the
advantage of it disappeared:
if (empty($a, $b, $c)) {
// you might want to check it again.
if (empty($a))
Hello PHP Internals!
I'd like to propose to make empty() a variadic, where if any arguments passed
in are considered empty, then false is returned - otherwise return true.
My reasoning for wanting this feature is as follows:1)It's a common scenario to
want to check multiple expressions for empty
Hi Kris,
Date: Thu, 12 Feb 2015 11:21:40 -0800
From: kris.cr...@gmail.com
To: tp...@hotmail.co.uk
CC: internals@lists.php.net
Subject: Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic
I'd say go ahead and draft an RFC with all the details of your proposed
change, then we can discuss
55 matches
Mail list logo
