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 dis
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 iss
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 (e
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, thoug
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 do
Hey Benoit,
> From: bensor...@neuf.fr
> Hi,
>
> I agree, this behaviour should be extended to all the is_* functions if
> possible.
>
I'm not sure we can do that for all of the is_* functions, since is_callable()
accepts up to three arguments rather than taking only a single argument like
t
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
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 wi
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 ent
// 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 hav
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 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 for
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, visit:
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 wer
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
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:
> http://marc.info
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, thi
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 Pavel,
> how will these examples work btw?
>
> // a.php
> declare(strict_types=1);
> function foo($fn) {
> $fn("1");
> };
>
> // b.php
> require 'a.php';
> foo(function (int $a) { return $a * 2; });
Result: catchable fatal error
Reason: invocation context is in strict mode
> // c.php
> f
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 w
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,
> 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 ful
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 next
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: https://github.
> 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: h
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 prov
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 un
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 the
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!
-To
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!
> 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 have
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!
>> 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!
> 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 val
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 trans
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()
> |> parseReq
> 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 langua
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 d
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 there.
> 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!
> 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 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
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 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 somethi
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,
> 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 mar
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 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 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 cov
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!
> 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 reques
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
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!
> 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 u
56 matches
Mail list logo
