Re: [PHP-DEV] Revive Number Format Separator RFC

[Thomas Punt]

> 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 proposed 
> implementation?

None that I can see/think of. Good luck with the RFC!

-Tom

Re: [PHP-DEV] Revive Number Format Separator RFC

[Thomas Punt]

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.
> >
> > I was granted karma, and published an initial RFC draft:
> > https://wiki.php.net/rfc/numeric_literal_separator.
> >
> > I would greatly appreciate help with the implementation, since I
> > don't have much experience with C and haven't contributed to PHP before.
> >
> > Also let me know if you have any ideas for improving the RFC.
> >
>
> I am happy to help with these. Let us take the RFC refinement and
> implementation details conversation off-list. Then come back when prepared
> to present for discussion.

I would think that pretty much the whole of the original implementation[1] 
should
be reusable (maybe some merge conflicts to fix only). But anyway, I can offer 
some
support with the implementation, if needed.

Thanks,
Tom

[1]: https://github.com/php/php-src/pull/1699

Re: [PHP-DEV] Revive Number Format Separator RFC

[Thomas Punt]

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 definitely agree that phone numbers and dates are not good use cases,
> and that there are usually better ways to write things like the number
> of seconds in a day or number of bytes in a gigabyte.

Storing dates in an integer format can be a valid use case if performance is a
concern. It is far faster and more compact to store and compare integer-based
dates than using objects for everything.

Anyway, if anyone would like to revive this RFC, then feel free to!

Thanks,
Tom

Re: [PHP-DEV] print with newline

[Thomas Punt]

> 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 language construct for parity with the echo and print.

For what it's worth, I actually wrote an article about exactly this. Whilst
it was more for didactic reasons (meaning that parts of the implementation
could/should be changed), you may find it to be a nice read:
https://phpinternals.net/articles/implementing_new_language_constructs_via_opcode_extending

Cheers,
Tom

Re: [PHP-DEV] definition of zendparse

[Thomas Punt]

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 used for the symbol 
definition name (instead of zendparse) in the generated parser[1], where it 
will be replaced with zendparse by the preprocessor.

Thanks,
Tom

[1]: 
https://gist.github.com/tpunt/c22aea1602594d6cfcc94f801d580241#file-zend_language_parser-c-L4489

Re: [PHP-DEV] RE: Requesting php-src Karma

[Thomas Punt]

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

[PHP-DEV] Requesting php-src Karma

[Thomas Punt]

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

Re: [PHP-DEV] Mailing list moderation

[Thomas Punt]

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 requests to
> moderate their participation both in that thread, and on a number of
> previous instances -- this is certainly not the first time these two users
> have converted an RFC discussion into a dick measuring contest.

+1

They've generated so much unnecessary noise on this mailing list that
I've had to set up rules in Outlook to automatically mark their emails as
read in order to skip past them.

Let's keep discussions on the mailing list on topic and fruitful.

-Tom

[PHP-DEV] [RFC][ACCEPTED] Flexible Heredoc and Nowdoc Syntaxes

[Thomas Punt]

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 patch (as requested by Derick), and will then

look into merging it into master and updating the language specification.


Thanks,

Tom

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes (voting restarted)

[Thomas Punt]

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 covered by each vote.


As per feedback here, I have updated the first voting question for additional 
clarification. This has restarted the vote for the first question only. The 
second vote will continue as normal, and both will still end on the same date 
(November 15th).


Sorry for the inconvenience.


-Tom

[PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

[Thomas Punt]

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

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Thomas Punt]

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 by 8 spaces, nothing is removed.

So let's say the ending marker is indented with [space][tab][space] and the 
body is indented with [tab][space][tab], by your logic, a [space] and a [tab] 
should be removed from the body's indentation? Or nothing at all?

The problem with such rules is that they bring more complication to the 
implementation when it comes down to the finer details. It is far better to 
simply disallow such nonsense to begin with.

A nice benefit of this (choosing a stricter approach to begin with) is that, 
should we see advantages to bringing more leniency to the current semantics 
(such as enabling the mixture of tabs and spaces), then we can enable this 
later without causing any new BC breaks. Whereas if we introduce a really 
loose-style syntax to begin with, then we cannot make it stricter later on 
without introducing new BC breaks.

-Tom

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Thomas Punt]

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 marker should be lined up to), not the indentation level 
from the start of the line (which may cause developers to indent the body text 
less to prevent leading whitespace, leading us back to the current situation of 
having indentation levels ruined by these syntaxes).


> this can lead to subtle bugs and annoyances.

I think this clause is a little too exaggerated. Once a developer understands 
that the closing token guides the indentation level of the body text, then the 
cause of the change in whitespace should be pretty obvious (if it's not already 
visually obvious from the fact that they must have broken the indentation level 
of their own code).

-Tom

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Thomas Punt]

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 necessary, 
but
I included it because it does help with readability when looking at the 
indentation
level of the heredoc and nowdoc (and subsequently how much whitespace will
be stripped from each line). With respect to the stripping of whitespace, 
however,
I feel that this is definitely necessary. If it was not stripped, then 
indenting the
closing token and body will cause a lot of whitespace to prepend every line in
the body of text. This is definitely not desirable, and may cause programmers to
continue to not indent the body of the heredoc/nowdoc, which leads us back to
where we currently are of having indentation of code ruined with such syntaxes.


Other languages follow these semantics of stripping whitespace from new lines

according to the indentation of the closing marker, such as Elixir (normal """ 
syntax)

and Ruby (special <<~ syntax).


Thanks,

Tom

Re: [PHP-DEV] Callout for bug tracker cleanup

[Thomas Punt]

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 something similar earlier this year, where I closed 109 bug reports

that pertained to ancient extensions. I made a list of these extensions[1],

along with a list of other extensions that appeared to be abandoned as

well. Perhaps after verifying/updating these lists of unused PECL packages,

we could simply close all bug reports related to them, and remove them

from the dropdown menu of all PECL packages (when reporting a new

bug). PHP 4-only extensions could also be removed from the docs, but

that's a different matter.


-Tom


[1]: https://gist.github.com/tpunt/0fe42cbf6527aa492c3f769e6fb526c0

[PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Thomas Punt]

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

[PHP-DEV] Bug Reports Targeting Ancient PECL Extensions

[Thomas Punt]

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 a "Won't Fix," given their abandoned status? I 
know Kalle

has tagged some of these bug reports with "Suspended," but given the 
unlikeliness

of these extensions ever being revived, it seems unnecessary to keep such bug

reports lying around in the bugs DB.


Thanks,

Tom


[1]: https://pecl.php.net/package/sam



[2]: https://bugs.php.net/search.php?cmd=display_name%5B%5D=sam

RE: [PHP-DEV] Change to Too Few Args Exception RFC

[Thomas Punt]

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 
:)
-Tom  

RE: [PHP-DEV] [RFC] Pipe Operator

[Thomas Punt]

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()
> |> parseRequest($$)
> |> buildPsr7Request($$);
>
> $response = loadConfig()
> |> buildDic($$)
> |> getApp($$)
> |> getRouter($app)
> |> getDispatcher($$, $request)
> |> dispatchBusinessLogic($$, $request, new Response())
> |> renderResponse($$)
> |> buildPsr7Response($$)
> |> emit($$);
>
> Here's what it would look like with a separate approach (more
> business-oriented):
>
> buildRequest() // (basically the first part of the previous example here)
> |> validate($$)
> |> convertToCommand($$)
> |> execute($$)
> |> convertToViewModel($$)
> |> render($$)
> |> convertToHttpResponse($$)
> |> emit($$)
>
> I think this is much more readable/clear than any event-driven or
> procedural approach.
> We know exactly what is going on, we will get clear stack traces (this
> could need some fine-tuning of the current PR - I didn't try it out yet)
> and we will be able to introduce intermediate steps with ease. In addition
> to all that, this will ease reactive programming by a lot, as piping is a
> natural fit for streams and all abstractions around streams.
>
> The syntax is also already effective in F# (you can write very expressive
> and easy to understand code with it) and now also landed in Hack.
>
> I'd say +10 to this proposal :D

I have to agree with this. The examples in the RFC probably don't show the
best examples of it - the pipe operator really clarifies code when nesting
numerous simple function calls. Quoting the example above:

$response = loadConfig()
 |> buildDic($$)
 |> getApp($$)
 |> getRouter($app)
 |> getDispatcher($$, $request)
 |> dispatchBusinessLogic($$, $request, new Response())
 |> renderResponse($$)
 |> buildPsr7Response($$)
 |> emit($$);

Without the pipe operator, it could look like the following:

$config = loadConfig();
$dic = buildDic(config);
$app = getApp($dic);
$router getRouter($app);
$dispatcher = getDispatcher($router, $request);
$businessResponse = dispatchBusinessLogic($dispatcher, $request, new 
Response());
$renderedResponse = renderResponse($businessResponse);
$psr7Response = buildPsr7Response($renderedResponse);
$response = emit($psr7Response);

That's a lot of unnecessary assignments, however, and the variable names
don't even provide any additional readability benefits because the function
names are already self-documenting.

More likely, the above code would be written as numerous nested function
calls:

$dispatcher = getDispatcher(getRouter(getApp(buildDic(loadConfig();
$response = 
emit(buildPsr7Response(renderResponse(dispatchBusinessLogic($dispatcher, 
$request, new Response();

Having to dissect expressions like the above from inside-out is not a natural
way to read how the operations are actually occurring though. It's far easier
to read them from left-to-right or top-to-bottom, and this is where the
advantages of the pipe operator can really be seen.

So I'm definitely +1 on this feature - it's something I really miss from Elixir.

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] PHP Attributes

[Thomas Punt]

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 transformations on PHP's underlying AST
>> that make it much nicer to use (namely better consistency). It is also
>> less fragile by having the abstraction between PHP's internal AST and
>> the AST that is exposed to userland (enabling for internal AST changes
>> without impacting the AST exposed to userland).
>
> I'm not sure. Both approaches make sense.

Whilst fragility is a concern, a bigger problem with not reusing
ast\parse_code() is that the AST produced will be different in even the
simplest of cases. For example, take the following simple expression:

$a> 2

With your attributes branch, this will produce an AST of:

object(ast\Node)#2 (4) {
    ["kind"]=> int(521) // ZEND_AST_GREATER
    ["flags"]=> int(0)
    ["lineno"]=> int(1)
    ["children"]=> [...]
}

Whereas with ast\parse_code(), the following AST will be produced:

object(ast\Node)#2 (4) {
    ["kind"]=> int(520) // AST_BINARY_OP
    ["flags"]=> int(256) // BINARY_IS_GREATER
    ["lineno"]=> int(1)
    ["children"]=> [...]
}

The php-ast extension transforms the special node types for>,>=, <, <=
into AST_BINARY_OP nodes with different flags set. This is just one
difference of many between the internal AST and the AST produced by
the php-ast extension.

>> 2. You mentioned about moving some of the php-ast extension into core.
>> I wonder if it would be better to just move the whole extension into the
>> core first, and then enable this functionality if the php-ast extension is
>> enabled.
>
> Even if we move php-ast into core (I think we will do it), it's going to
> be optional.
> However attributes should always work.

If we're going to reuse ast\parse_code(), then we will need the whole php-ast
extension in the core. It could therefore be made similar to the pcre, date,
Reflection, SPL, etc extensions, where it cannot be disabled.

>> Also, slightly tangential, but the RFC says attributes are supported on
>> class constants, yet doc comments (IIRC) are not. I wonder if support
>> for doc comments should be added for class constants?
>
> it is already implemented.

Oh right, my mistake. It does not seem to be exposed through php-ast or
reflection then.

> Thanks. Dmitry.
>>
>> Thanks,
>> Tom

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] PHP Attributes

[Thomas Punt]

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 values.
>
> These expressions are not evaluated, but stored as Abstract Syntax Trees, and 
> later may be accessed (node by node) in PHP extensions, preprocessors and PHP 
> scripts their selves. I think this ability may be useful for "Design By 
> Contract", other formal verification systems, Aspect Oriented Programming, etc
>
>
> https://wiki.php.net/rfc/attributes
>
>
> Note that this approach is going to be native, in contrast to doc-comment 
> approach that uses not well defined syntax, and even not parsed by PHP itself.
>
>
> Additional ideas, endorsement and criticism are welcome.

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 transformations on PHP's underlying AST
that make it much nicer to use (namely better consistency). It is also
less fragile by having the abstraction between PHP's internal AST and
the AST that is exposed to userland (enabling for internal AST changes
without impacting the AST exposed to userland).

2. You mentioned about moving some of the php-ast extension into core.
I wonder if it would be better to just move the whole extension into the
core first, and then enable this functionality if the php-ast extension is
enabled.

Also, slightly tangential, but the RFC says attributes are supported on
class constants, yet doc comments (IIRC) are not. I wonder if support
for doc comments should be added for class constants?

Thanks,
Tom   
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: Improving PHP's type system

[Thomas Punt]

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 the
> current namespace." and this makes "use" confusing.

I don't think this additional usage of "use" makes it any more confusing.
Many keywords are reused elsewhere, including "use":
 - namespace importing
 - variable importing for closures
 - trait importing

(Ditto with "as.")

Thanks,
Tom   
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] var deprecation

[Thomas Punt]

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 still be reused in other places
if we so wish (as has been done with "use" for namespaces, traits, and
closures, as well as "as" in foreach, namespaces, and traits).

So whilst Java is adding "var" for a short-hand declaration via type inference,
it is only applicable to local variables and not properties. Deprecating "var"
in this context for PHP is therefore not really the inverse of what Java is 
doing.

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC Discussion] "var" Deprecation

[Thomas Punt]

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 been documented.
> - Any impact this may have on SAPIs, extensions, or the opcache.
> - Any assistance or guidance on creating the patch (I've never written C or
> worked with the core codebase before).

I'm still on the fence about this, but here's a patch for it:
https://github.com/php/php-src/compare/master...tpunt:deprecate-var

Thanks,
Tom   
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: [RFC Proposal] var keyword deprecation/removal

[Thomas Punt]

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 that there were better reasons for deprecating PHP 4-style
constructors over the simple redundancy argument. Specifically, there was
confusion as to when a PHP 4-style constructor would actually be
considered a constructor (see the RFC [1] for examples). With the var
keyword, there's no ambiguity like this.

Whilst the language purist in me would like to remove redundant things like
this, I feel that it's a rather unnecessary BC break to introduce. So I'm not
entirely decided on this.

Thanks,
Tom

[1]: https://wiki.php.net/rfc/remove_php4_constructors  
  

[PHP-DEV] RE: [RFC][VOTE] Number Format Separator

[Thomas Punt]

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!

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC][VOTE] Number Format Separator

[Thomas Punt]

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 they'll
have time to review it within the next week.

> Regards //Björn Larsson

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][VOTE] Number Format Separator

[Thomas Punt]

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 unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] Number Format Separator

[Thomas Punt]

> 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.com/php/php-src/pull/1699

Just bringing this back up to the top because of the recent influx in internals
activity. I'm hoping to put this to vote tomorrow, so if anyone has any
questions or problems with this RFC, then please let me know!

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] Number Format Separator

[Thomas Punt]

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 provided by a userland function. Maybe
> it's worth pointing that out in the RFC.

Thanks for the comments - I've update the RFC accordingly.

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Number Format Separator

[Thomas Punt]

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.com/php/php-src/pull/1699

Thanks,
Tom
  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] [Discussion] Short Closures

[Thomas Punt]

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 version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob

Whilst I'd like to see a more expressive syntax for closures (and many other
things) in PHP, I'm personally -1 on your proposal. The feature feels too
inconsistent with the syntax and semantics of current PHP constructs for the
following reasons:
1) The automatic binding of variables from the outer scope to the inner scope.
2) The optional use of parentheses for parameter definitions, but only when a
single argument is used.
3) The optional use of braces for the function body, but only when a single
expression is used.
4) The automatic returning of the expression, but only when it is alone, and
only if the braces are omitted.

These four differences create further special cases for people to learn and
have no precedence in the language at all. They seem more like Rubyisms than
PHPisms.

Whilst we're on the topic of a terser syntax for closures though, Elixir has an
even shorter syntax:
&(&1 + &2)

The &() denotes an closure definition; the  is used to create placeholders,
where N corresponds to the argument number. The ampersand obviously cannot be
reused for this in PHP, but the dollar sign could:
$func = $($1 + $2);
var_dump($func(3, 4)); // int(7)

This syntax should only be used in trivial scenarios, though, and comes with
the disadvantage of no type information.

Thanks,
Tom
  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Allow __toString() to throw exceptions

[Thomas Punt]

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
 serves its purpose throwing Fatal error now, even if it is non-standard way.

The problem with not enabling __toString to throw exceptions is that if any
exceptions thrown are by the engine itself (for things like uncallable 
functions),
then the method returns an unrelated E_ERROR regarding the inability to
throw exceptions.

The code example [1] shows this where the old message was:
Fatal error: Call to undefined function a() in...

and now after the inclusion of exceptions in the engine, it is:
Fatal error: Method Test::__toString() must not throw an exception in...

This is obviously not an overly helpful response, and the E_ERROR cannot be
caught either.

Thanks,
Tom

[1] http://3v4l.org/eGc1d

  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Exception hierarchy: open issues

[Thomas Punt]

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 Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Make empty() a Variadic

[Thomas Punt]

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 semantics
empty() should have).

Thanks to all who participated in the discussions and voting of this RFC!

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Thomas Punt]

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
 function foo($fn) {
 $fn(1);
 };

 // d.php
 ?php
 declare(strict_types=1);
 require 'c.php';
 foo(function (int $a) { return $a * 2; });

Result: no error
Reason: invocation context is in weak mode

 I can't find this in the RFC. I'd intuitively expect error in the
 first example and the second one to work OK.

Correct :)

-Tom

  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] STH and the 3 RFCs

[Thomas Punt]

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 can be done unintentionally [2] because of 
the
caller-deciding semantics. These examples can be further extended into wrapper
classes, nested library dependencies, etc.

Sure, you could argue that this could easily be turned off by simply removing 
the
top declare() statement of that library, but modifying the library in itself 
introduces
complications - especially when using dependency managers like Composer.

[1] https://gist.github.com/tpunt/4830d18d47e2df021c2f
[2] https://gist.github.com/tpunt/eecfed2495bdccb73632

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RE: STH and the 3 RFCs

[Thomas Punt]

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, but the first
example could be could considered design by intention to enforce
users to pass in the correct argument types.


 Thanks,

 Theodore

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] STH and the 3 RFCs

[Thomas Punt]

 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 - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Make empty() a Variadic

[Thomas Punt]

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 were raised:
1. This will promote the creation of poor code.
2. The proposed semantics of empty() is wrong. It should be equivalent to 
logically
AND'ing empty()'s arguments together - just like with isset().

To readdress these two points:

1.
Any feature that reduces the amount of written code can be said to make it
easier to write code - regardless of whether this is good or bad code. That
part is up to the developer.

Perhaps the examples in my RFC do not portray this feature in the best of
lights - they were simply meant to show the more extreme usages of empty()
in popular, real-world codebases. So let me provide some statistics.

I ran the following egrep on a number of CMSs (the regular expression used isn't
perfect, but it still gives some sort of approximation):

egrep -rio '(empty\(.*\) *(\|\| *empty\(.*\))+)|(!empty\(.*\) *( 
*!empty\(.*\))+)' project_dir/ | wc -l

Results:
WordPress: 50
OpenCart: 22
phpbb: 36
Drupal: 74
SMF2.1: 266
Joomla: 23

So the proposed short-hand notation of empty() in this RFC does have its
usages. Just as a full disclaimer though, framework codebases will not see
this same usefulness since they don't handle business-specific validation logic
on input fields, web service data, etc (which seems like the predominant usage
of multiple empty()'s in a single condition).


2.
The falsy semantics of empty() means that inlining its behaviour to exactly 
match
isset() isn't logical.

For example, we can roughly assert that `empty() = ! isset()`. This holds true
with the current semantics proposed by this RFC:

$defined = 1;
// $undefined;
var_dump(empty($defined, $undefined) === ! isset($defined, $undefined)); // 
bool(true)

If empty()'s arguments were logically AND'ed together, then the above assertion 
would
not hold true.


So those are the two arguments I'm aware of - if anyone in the -1 camp has any
other reasons, then please do raise them!

Thanks,
Tom

 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: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Make empty() a Variadic

[Thomas Punt]

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 arguments passed into empty() are considered falsy, then true
 will be returned

 i.e. it doesn't check whether the arguments are 'empty', it's checking
 whether they are 'all set and not falsy'. Having a function do
 something different to what it's name suggests will lead to it being
 used incorrectly a lot of the time.

Yes, I think this is probably the discursive area that is causing a divide in 
vote.
The only compromise I can think of (though not sure on its feasibility) would be
to have a flag as the last parameter that defaulted to logically AND'ing its 
args
with the ability to switch the semantics to logically OR the args.

 The other reason I voted no, is that I just don't think this adds
 enough to the language to be implemented in core. For at least two of
 the examples in the RFC the desired functionality could be implemented
 in userland.

 The size of the PHP core codebase is already unwieldy. I think any
 suggested addition needs to have a clear advantage over being
 implemented in userland

I could understand this POV if it caused a lot of changes, but the patch is
pretty simple a small. I think the potential benefits brought by this feature
is worth its weight against 10 lines of additional code in the language grammar
file.

 cheers
 Dan

Thanks for reclarifying the issues you have with this RFC.

-Tom
  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [VOTE] Make empty() a Variadic

[Thomas Punt]

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/?l=php-internalsm=109836951711930

 I can't find the discussion prior to that though.

 cheers,
 Derick

Thanks for the link. I wasn't aware this had come up in the past.

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [VOTE] Make empty() a Variadic

[Thomas Punt]

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: http://www.php.net/unsub.php

RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

[Thomas Punt]

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 form), then by 
enabling
spaces in that input, it would destroy the overall usability of it.

One scenario I have in mind for this is validating $_GET information for a 
RESTful web
service. Having potentially an infinite number of URIs that all point to the 
same resource
isn't good:

/users/1
/users/%201
/users/1%20
/users/%201%20
/users/%201%20%20
etc.

In this case, I don't want to accept any leading or trailing spaces for the 
user ID. So I
would therefore not be able to use an `int` type hint because its acceptance 
rules would
be too lax.

If spaces are not accepted in stringy ints, and I want to pass a stringy int 
that may have
leading or trailing spaces in it, then I know I can simply apply a trim() to it 
before passing
it into a function that's expecting only an int. This way, the usability of 
integer-only inputs
(as string or ints) isn't compromised by the rules being too weak.

 The takeaway from this seems to be that the approach of tightening the
 existing rule-set and applying it to both internal functions and new
 user-land code is viable, and does not cause the sky to come down falling.
 Preliminary tests suggest it actually finds real potential problems.

 More tomorrow.

Overall, a big +1 on this though! The type coercion rules at the moment are far
too lax to be considered useful in most situations IMO.

 Zeev

Thanks,
Tom   
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] Make empty() a Variadic

[Thomas Punt]

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 to write less verbose code for what 
seems like a common scenario in code bases. Whilst the examples I shows may not 
be demonstrating the highest quality of code out there, they do show that code 
does exist (and in popular projects too) that could benefit from having this 
feature included  into PHP.


 cheers
 Dan

Thanks,
Tom   
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] Make empty() a Variadic

[Thomas Punt]

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 empty, i.e. AND things together.
 
 If we enable variable arity then it will join the group of function
 where no user sanely can remember if in_array/etc. take the
 needle/haystack first or second argument. I.e. whether it will OR or AND
 all arguments.

My rationale for this is that empty() performs an inverse check to isset(), so 
I feel it should have inversed behaviour too (i.e. logically OR'ing its 
arguments together instead of logically AND'ing them together). To quote what 
Andrea wrote in the pre-RFC discussion thread:
 From: Andrea Faulds Date: Fri Feb 13 06:31:38 2015 So !empty($a, $b, $c) 
 would work similarly to isset($a, $b, $c), and similarly, !isset($a, $b, $c) 
 would work similarly to empty($a, $b, $c).
This means that we keep the (rough) equivalence of `empty() == !isset()` - 
which is true since a variable that is not set or is null is going to be a 
falsy value, so both the `empty()` and `!isset()` expressions will return TRUE. 
Likewise for `!empty() == isset()` - if an argument does not have a falsy 
value, then empty() will return FALSE. isset() will return TRUE on that same 
value since a variable cannot be truthy and either not set or null.
Now, if we changed the semantics to how you're seeing them, then we would have 
the following:?php$a = true;$b = 'b';// $c;var_dump(empty($a, $b, $c) === 
isset($a, $b, $c)); // true
This behaviour seems incorrect to me, since *both* expressions will return 
FALSE. So how can two constructs that have inverse purposes be equal to each 
other on the same input?
With the currently proposed behaviour, the empty() expression will return TRUE, 
whilst the isset() expression will return FALSE, giving the inverse result.
 From http://php.net/manual/en/function.isset.php :
 If multiple parameters are supplied then isset() will return TRUE
 only if all of the parameters are set. Evaluation goes from left to
 right and stops as soon as an unset variable is encountered.
 
 But this is an AND: ... if all ... are set:
 
 isset($a,$b) behaves like isset($a)  isset($b)
 
 IMHO this absolutely violates your POLA because as I said this is also
 how I would assume empty() with variable arguments would work: Only
 return true if all are true.
If we had an empty-based function that did not perform a reverse check to 
isset(), such as `not_empty()`, then I'd say it should behave like isset():
var_dump(not_empty($a, $b, $c) === isset($a, $b, $c)); // true
But because this is not the case for empty(), I'd say it would be confusing for 
it to act the same way isset() does.
 My personal opinion is that any attempt to change this is ill-fated
 because people will no be able to memoize the exact usage of it because
 it would mean different things to different people and would just add
 more confusion.

My aim is to make empty()'s behaviour intuitive so that users don't have to 
memorise its semantics.

 
 - Markus
 
Thanks for your input Markus and I hope you can better see where I am coming 
from with my current RFC :)

-Tom


  

RE: [PHP-DEV] [RFC] Make empty() a Variadic

[Thomas Punt]

// 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 assumed from the start that empty() would only return true
 if *all* of the entries are empty, i.e. AND things together.
 
 If we enable variable arity then it will join the group of function
 where no user sanely can remember if in_array/etc. take the
 needle/haystack first or second argument. I.e. whether it will OR or AND
 all arguments.
My rationale for this is that empty() performs an inverse check to isset(), so 
I feel it should have inversed behaviour too (i.e. logically OR'ing its 
arguments together instead of logically AND'ing them together). To quote what 
Andrea wrote in the pre-RFC discussion thread:
 From: Andrea Faulds
 Date: Fri Feb 13 06:31:38 2015

 So !empty($a, $b, $c) would work similarly to isset($a, $b, $c), and 
 similarly, !isset($a, $b, $c) would work similarly to empty($a, $b, $c).
This means that we keep the (rough) equivalence of `empty() == !isset()` - 
which is true since a variable that is not set or is null is going to be a 
falsy value, so both the `empty()` and `!isset()` expressions will return TRUE. 
Likewise for `!empty() == isset()` - if an argument does not have a falsy 
value, then empty() will return FALSE. isset() will return TRUE on that same 
value since a variable cannot be truthy and either not set or null.
Now, if we changed the semantics to how you're seeing them, then we would have 
the following:?php$a = true;$b = 'b';// $c;var_dump(empty($a, $b, $c) === 
isset($a, $b, $c)); // true
This behaviour seems incorrect to me, since *both* expressions will return 
FALSE. So how can two constructs that have inverse purposes be equal to each 
other on the same input?
With the currently proposed behaviour, the empty() expression will return TRUE, 
whilst the isset() expression will return FALSE, giving the inverse result.
 From http://php.net/manual/en/function.isset.php :
 If multiple parameters are supplied then isset() will return TRUE
 only if all of the parameters are set. Evaluation goes from left to
 right and stops as soon as an unset variable is encountered.
 
 But this is an AND: ... if all ... are set:
 
 isset($a,$b) behaves like isset($a)  isset($b)
 
 IMHO this absolutely violates your POLA because as I said this is also
 how I would assume empty() with variable arguments would work: Only
 return true if all are true.
If we had an empty-based function that did not perform a reverse check to 
isset(), such as `not_empty()`, then I'd say it should behave like isset():
var_dump(not_empty($a, $b, $c) === isset($a, $b, $c)); // true
But because this is not the case for empty(), I'd say it would be confusing for 
it to act the same way isset() does.
 My personal opinion is that any attempt to change this is ill-fated
 because people will no be able to memoize the exact usage of it because
 it would mean different things to different people and would just add
 more confusion.
My aim is to make empty()'s behaviour intuitive so that users don't have to 
memorise its semantics.
 - Markus
Thanks for your input Markus and I hope you can better see where I am coming 
from with my current RFC :)
-Tom  

RE: [PHP-DEV] [RFC] Make empty() a Variadic

[Thomas Punt]

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 complaint about naming.
 empty_expressions ... I'll give you an empty expression!
 
 But overall +1 on functionality and patch.
 
 Cheers!
 
 Leigh.

Thanks for the feedback :)
-Tom  

[PHP-DEV] [RFC] Make empty() a Variadic

[Thomas Punt]

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 the is_*() functions into this RFC because my main 
priority is to get this particular feature into PHP 7.0 before feature freeze. 
Provided I have some free time over the next week, I'll write up another RFC + 
patch to cover the is_*() functions.
Thanks,Tom

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

[Thomas Punt]

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. 
 So !empty($a, $b, $c) would work similarly to isset($a, $b, $c), and 
 similarly, !isset($a, $b, $c) would work similarly to empty($a, $b, $c).
 
 But that’s just my opinion. :)
 --
 Andrea Faulds
 http://ajf.me/

Yeah, my mistake. That's what I meant - empty will return TRUE if *any* of its 
arguments are considered empty, and FALSE otherwise. So the following two 
pieces of code are analogous:
# this:if (empty($a) || empty($b) || empty($c)) {// error here}
# is the same as this:if (empty($a, $b, $c)) {// error here}
# and this:if (!empty($a)  !empty($b)  !empty($c)) {// all good!}
# is the same as this:if (!empty($a, $b, $c)) {// all good!}
Sorry for the confusion :p
-Tom  

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

[Thomas Punt]

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 their usages seem a lot less common. What does 
everyone else think?
 
 François

Thanks, Tom   

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

[Thomas Punt]

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 all type related is_* functions and be  similar to
 issets behavior (return false if at least one argument is not of the
 given type).
 
 Thanks,

Agreed on that. It would be better for consistency's sake.
-Tom  

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

[Thomas Punt]

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)) {
 //blah blah.
 } else if (empty($b)) {
 
 }
 }
 


Having empty() return TRUE if *all* arguments are empty, and FALSE otherwise 
doesn't seem to be as useful (at least from what I've seen in code).


It's less common to see:

if (empty($a)  empty($b)  empty($c)) {}

than:

if (empty($a) || empty($b) || empty($c)) {}

Plus then the semantics wouldn't be inline with isset(), which could be 
somewhat confusing to users.

 
 -- 
 Reeze Xia
 http://reeze.cn

Thanks,
Tom   

[PHP-DEV] [DISCUSSION] Make empty() a Variadic

[Thomas Punt]

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 values. I frequently see both of 
the following pieces of code in projects:#1if (empty($a) || empty($b) 
|| empty($c)) {// error here}
#2if (!empty($a)  !empty($b)  !empty($c)) {// all good!}
Both of the above examples could be shortened if empty() was made to accept 
multiple arguments:#1if (empty($a, $b, $c)) {// error here}
#2if (!empty($a, $b, $c)) {// all good!}
This creates more compact code that is (in my oppinion, at least) easier to 
read.
Some code from real-world projects that could benefit from this 
feature:WordPress (one of many): 
https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/template.php#L1963OpenCart:
 
https://github.com/opencart/opencart/blob/45fc863fa068d82b5280890e6466a198faa54bff/upload/admin/controller/openbay/ebay_profile.php#L128phpbb:
 
https://github.com/phpbb/phpbb/blob/040d451dcca9ae54d8f4b7bdd2f231033765a8f2/phpBB/phpbb/notification/method/jabber.php#L48

2)Users have brought up the want to pass in multiple arguments into empty() 
before, such 
as:http://stackoverflow.com/questions/4993104/using-ifempty-with-multiple-variables-phphttp://stackoverflow.com/questions/10950470/check-if-multiple-strings-are-empty
There have been solutions brought up by users to emulate a variadic empty, like 
[1][2], however for unset variables their solutions simply don't work.

So all in all, it seems like a simple feature to add for a short-hand notation 
of checking multiple expressions for emptiness (which seems like a common 
use-case for users). It has no BC implications and no real downsides (at least 
I couldn't think of any). I have created a patch [3], and if the feedback is 
positive, then I'll create an RFC and submit a PR.
Thanks,Tom
[1] http://stackoverflow.com/a/7798842/4530326[2] 
http://icoded.it/php-time-saving-function-to-check-multiple-variables-for-empty-values/[3]
 
https://github.com/tpunt/php-src/commit/66c563829775770507147872b98320cdfcb6c51c
 

RE: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

[Thomas Punt]

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 and vote on it.  On the surface, it looks like
 a useful feature that wouldn't break any existing code.
 
 --Kris

Will do! Also, apologies for the email formatting - I didn't realise my message 
was going to be mangled when sent...