Re: [PHP-DEV] [VOTE] Interface Default Methods

[John Bafford]

On Jul 11, 2023, at 13:42, Larry Garfield  wrote:
> 
> On Tue, Jul 11, 2023, at 5:28 PM, Robert Landers wrote:
>> 
>> IMHO, using a shared base class reflects the inheritance better
>> because they are siblings (at least these appear to be logical
>> siblings out of context, IMHO) and should look like siblings in a
>> class diagram. Their current dis-jointed-ness strikes me as odd and
>> the usage of traits in this way strikes me as an anti-pattern. But I
>> came from a PHP world where traits were nearly forbidden or used very
>> sparingly.
> 
> Traits are a surgical tool with a narrow set of uses, and systems that 
> over-use them cause problems.  (You know which framework you are...)  But 
> this is one of their main valid uses.
> 
> In context, the classes are not siblings, and it would be incorrect for them 
> to extent from a base class.  They just both happen to implement the same 
> *interface*, but that the same as having the same "is a special case of" 
> relationship with a base class.
> 
> Having a common base class instead would, as noted before, mean as soon as I 
> added a third "carries" option, I'd have to add four more base classes to 
> cover all combinations.  It quickly gets absurd, and those base classes have 
> no valid type usage; they're purely there as an alternative to copy-paste.
> 
> Using inheritance as an alternative to copy-paste is the wrong way(tm) to do 
> it.  Both inheritance and copy-paste.  Freshman CS classes still love to talk 
> about inheritance as a great thing for code reuse but... it's really not, and 
> many of the 21st century languages have been drifting away from that.
> 
> Traits/default-method-interfaces are a better alternative that doesn't 
> conflate "copy-paste avoidance" with "is a special case of."  Honestly, I 
> almost never use class inheritance in my greenfield code these days.  


I'm stating my +1 for this feature (though I can't vote since I lack vote 
karma), and also want to point that this is a feature in Swift as well, and 
used extensively through its standard library. (The actual mechanics are 
somewhat different, and significantly more powerful, both for good and ill. I'm 
handwaving a bit to not get bogged down in details that don't/can't matter for 
PHP.)


A basic example in Swift's standard library is the Equatable and Comparable 
interfaces. Both have partial implementations provided. Between the two, if you 
implement the == and < operations, the stdlib provides !=, <=, >, and >= 
automatically, but you can override them if desired by providing an explicit 
implementation. This is used pretty much everywhere; most of the builtin types 
(like Int, Float, String, and Array, which otherwise have no relation to each 
other and definitely don't inherit from some base type) implement Equatable and 
Comparable.

Another example is the Sequence interface, which comes with a set of default 
implementations for standard sequence algorithms, such as map, first, min/max, 
contains, etc. This allows all types of sequences to have the functionality 
expected of a sequence without needing to redundantly implement basic 
operations (unless desired) or participate in inheritance.

This clear distinction between what a type _is_ (its type and inheritance tree) 
and what a type _can do_ (the interfaces it implements) is really important 
when you start piling on the interfaces. Swift's standard library comes with a 
laundry list of interfaces that provide partial or complete default 
implementations, and it's entirely reasonable to combine these together. 
Consider, for example, a type that implemented each of Sequence, Collection, 
Encodable, Decodable, Equatable, and Hashable (such as Array or Dictionary). 
Creating a sane inheritance tree for that would be difficult. (And that's 
before considering that an array or dictionary should itself be 
Encodable/Decodable/Equatable/Hashable if its elements (and keys) have those 
properties. In Swift, the implementation for Array and Dictionary is largely 
the details of managing data storage. Useful algorithms get automatically 
inherited from default implementations from their many interfaces without 
needing a common parent class for both arrays and dictionaries, which are both 
structs which can't have inheritance anyway.)


I'll also point out that (in both PHP and Swift) enums can't participate in 
inheritance, but can implement interfaces. If one wanted to provide a default 
implementation for an interface used an enum, an abstract class isn't an option 
at all.


Anecdotally, outside of framework-mandated inheritance, the vast majority of my 
types in Swift are structs, enums, and classes with no inheritance, and many 
have interfaces that have some default implementation provided. Most of my PHP 
classes that have inheritance would be better served with interfaces + default 
implementations; they use inheritance only because it is currently the least 
bad way to make them work. Inheritance 

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[John Bafford]

Hi everyone,

Apologies for not including context and responding to 40 emails all at once, 
I’m not at a computer (and won’t be for a few weeks).

Given the comments I read in the thread, I wanted to make some key points that 
I hope will clarify my intent behind the proposal:

* The primary motivation behind this RFC is the ability to indicate intent when 
iterating over a collection without caring about its values. Any performance 
benefits are strictly secondary.

* I explicitly chose void, rather than null, because in PHP, null is a value, 
and personally, I found it exceedingly weird to write `foreach($arr as $key => 
something-that-is-normally-a-value-except-in-this-case)`. In fact, if I’m 
remembering correctly, I actually waited until PHP 7.1 added `void` for this 
RFC specifically so I wouldn’t have to invent new syntax.)

* If PHP had either convention or special handling for _ or $_ as a “ignore 
this” destination, I wouldn’t have made the proposal.  However, it doesn’t; _ 
can (apparently!) be a constant, and is also a function, and $_ has no special 
handling (and I bet it’s actually used to contain values that are used in at 
least one application).

* From my recollection, unless something has changed drastically since 7.0 and 
8.x, the only possible performance hit from the patch would be in the parser, 
as there is obviously some additional logic. However, at runtime, it can only 
be faster, because in the presence of a `void` foreach value target, the parser 
simply doesn’t emit the opcode for writing a value there.

* I know it’s popular to say that `foreach(array_keys())` is rare; however, 
_every_ PHP application I’ve ever touched uses it at least once, and often 
multiple times. So, I’m equally surprised to find that there are people who 
have never used it. (If I had to guess, it’s that I make heavy use of the fact 
that arrays are ordered maps, and so, simply the keys and their order _are_ 
often a significant and useful piece of information on their own, especially in 
arrays that are used as mapping tables.)

I think that covers all the criticisms I saw, but if I missed anything, please 
let me know and I’ll respond once I have a chance. After I get back home, I’ll 
update the RFC with the results of this thread and bring it to a vote.

Thanks,

-John

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

Re: [PHP-DEV] Request for couple memory optimized array improvements

[John Bafford]

Hi Riikka,

> On Aug 31, 2020, at 14:13, Riikka Kalliomäki  
> wrote:
> 
> A common pattern that I've seen that could dearly use PHP internal
> optimization, if possible, would be:
> 
> foreach (array_keys($array) as $key) {
> }

I have a draft RFC (https://wiki.php.net/rfc/foreach_void) and patch 
(https://github.com/jbafford/php-src/tree/foreachvoid against php 7.0, I think) 
that helps with this, by allowing the following syntax:

foreach($iterable as $key => void) { ... }

This would iterate over the keys of the iterable, and does not retrieve the 
values at all.

In theory, this should be a general performance win any time one needs to 
iterate over only the keys of an iterable, because it does not require the use 
of an O(n) iteration and building of the array that array_keys() would, plus it 
works on non-array types (such as generators or iterators). It also is more 
performant than foreach($iterable as $key => $_) {}, because it omits the 
opcode that instructs the engine to retrieve the value. (Presumably, a future 
direction could include using this request to inform generators or iterators to 
only return keys, and not values, which could further improve performance, 
especially if value generation is expensive. But that is out of scope for this 
RFC.)

If this is something we'd like for PHP 8.1 and there are no major objections to 
the idea, then after 8.0 is released, I can move the RFC out of Draft and into 
Under Discussion, and presuming a vote passes, I'll update the patch as 
necessary to work against 8.0. But my time is limited and I'm not willing to 
put further time into the code unless an RFC vote passes.

Thoughts anyone?

-John

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

Re: [PHP-DEV] [RFC] Guard statement

[John Bafford]

Pavel,

On May 16, 2020, at 05:13, Pavel Patapau  wrote:
> 
> Hello everyone,
> 
> I want to propose new syntax addition - guard statement, that executes code 
> only if expression equals false and must contain control-flow changing code, 
> and written a respective RFC:
> 
> https://wiki.php.net/rfc/guard_statement
> 
> 
> Implementation in progress.
> 
> I started work before this proposal https://externals.io/message/110107 and 
> respected some moments in the RFC.
> 
> 
> Thanks for consideration,
> Pavel


Regarding this part of the proposal:

> Body of statement must contain code that changes control flow: return, throw, 
> goto. Also, in a loop context, you can use break or continue.
> 
> If compiler doesn't find any of those statements, it will search selection 
> type statements(if with else|try/catch/finally|switch) and ensures that every 
> element of these statements contains return, throw, goto.

I feel that from an implementation standpoint, this could be fairly complex, 
especially since code such as:

guard (COND) else exit;
guard (COND) else call_some_function_that_calls_exit();

ought to compile without warnings. (Exit was explicitly included in my original 
proposal on the mailing list.) Some languages allow this by marking functions 
with a noreturn attribute (C, Swift < 3). Swift >= 3 solves this problem by 
having a "Never" return type, which is validated by Swift's type checker, 
requiring all code paths to also call another function returning Never. (As an 
implementation detail, Never is an enum with no cases.)

Otherwise, you would have to write

guard (COND) else {
exit;
return;
}

to satisfy the parser, which is silly.

I would suggest an alternative that is conceptually simpler and allows for this 
use case.

We can observe that if we slightly loosen the restriction that the _compiler_ 
must be able to do a full call path analysis, a guard statement can also be 
thought of as:

guard (COND) else {
STATEMENTS;

throw new \GuardFailureError;
}

That is, the else clause ends with a compiler-generated fatal error. This means 
the compiler itself doesn't _have_ to do a full analysis of every call path in 
the STATEMENTS to ensure proper exit; the runtime can trap as well.

This allows us to be a bit more flexible: if the compiler can prove one way or 
the other, it can either fail compilation, or else omit generating the opcodes 
for throwing the GuardFailureError. But code that the compiler _can't_ prove 
(such as the previously mentioned code-that-calls-exit) should still be allowed.

If we later add language support for a noreturn attribute, or some other 
mechanism to account for that, then we are in a position to allow for that 
complexity in the parser and remove the runtime handling. It would obviously be 
preferable if the compiler can catch errors in all cases, but when it can't 
(and php's dynamicity makes this a hard problem), I think it's acceptable that 
the runtime can serve as a fallback.

-John

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

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

[John Bafford]

Benas,

> On May 15, 2020, at 04:33, Benas IML  wrote:
> 
> Hey,
> 
> `guard` would be a keyword this means that all of the classes, interfaces and 
> traits named Guard would be illegal. Therefore Laravel's `Guard` interface 
> would be incompatible with PHP 8 which in turn means thousands of web 
> applications would be too.
> 
> Best regards,
> Benas Seliuginas


If the parser were sufficiently smart, I don't think 'guard' would actually 
conflict with a class or function named 'guard'. If the syntax were:

guard (EXPRESSION) else STATEMENT_OR_BLOCK

then, 'guard' could not conflict with a class name, because there's no existing 
syntax that would fit the pattern of a type name followed by a parenthesis — 
you can't call a type name as if it were a function. Even if you could, it 
would still not conflict with a function call, because the 'else' keyword after 
the close parenthesis would not be valid syntax immediately following a 
function call.

So the main question there is, is the parser sufficiently smart to be able to 
see 'guard' and look ahead for the 'else' to disambiguate a function call from 
a guard statement?

-John

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

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

[John Bafford]

Benas,

> On May 10, 2020, at 15:19, Benas IML  wrote:
> 
> Hello,
> 
> I think that we SHOULD not introduce a new keyword (e. g.  guard) since that
> would be a "major major" backwards incompatibility. "Guard" is a really 
> generic
> word and a great example of that is Laravel and their authentication guards.
> 
> In general, I don't think that early returns require a seperate syntax and/or
> block statement since a simple `if (...) { return; }` is already sufficient
> enough.
> 
> Best regards,
> Benas Seliuginas


I think there's three main reasons for guard, as opposed to if:

1) It further and clearly establishes intent: if you see guard, you have more 
information about the programmer's intent and what the code will actually do.
2) It prevents having to negate the condition: guard (is valid) else, instead 
of if (not valid) then; negations impose additional cognitive load when 
attempting to understand code, especially if your condition already has a 
negation.
3) The language provides a guarantee that if the guard condition is not met, 
execution can not proceed past the else clause. This helps prevent accidental 
fall-through, such as if you wrote: if(!$valid) { terminate(); } expecting it 
to end execution (e.g. via a throw or exit), but for some reason it failed to 
do so.

To take an idea from Ralph's original proposal, perhaps some syntax like "if 
guard (condition) else ...". In this context, guard could not possibly be 
confused with a function from the parser's point of view, instead serving as an 
intent modifier to if.

-John

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

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

[John Bafford]

Hi Ralph,

> On May 10, 2020, at 11:49, Ralph Schindler  wrote:
> 
> Hi!
> 
> 
> # Intro
> 
> I am proposing what is a near completely syntactical addition (only change is 
> to language.y) to the language. The best terminology for this syntax is are: 
> `return if`, "return early", or "guard clauses".
> 
>  see: https://en.wikipedia.org/wiki/Guard_(computer_science)
> 
> Over the past few years, I've seen a growing number of blog posts, conference 
> talks, and even tooling (for example code complexity scoring), that suggest 
> writing guard clauses is a good practice to utilize.  I've also seen it more 
> prevalent in code, and even attempts at achieving this with Exceptions (in an 
> HTTP context) in a framework like Laravel.
> 
>  see abort_if/throw_if: https://laravel.com/docs/7.x/helpers#method-abort-if
> 
> It is also worth mentioning that Ruby has similar features, and I believe 
> they are heavily utilized:
> 
>  see: https://github.com/rubocop-hq/ruby-style-guide#no-nested-conditionals
> 
> 
> # Proposal
> 
> In an effort to make it a first class feature of the language, and to make 
> the control flow / guard clauses more visible when scanning code, I am 
> proposing this in the syntax of adding `return if`.
> 
> The chosen syntax is:
> 
>  return if ( if_expr ) [: optional_return_expression] ;
> 
> As a contrived example:
> 
>function divide($dividend, $divisor = null) {
>return if ($divisor === null || $divisor === 0);
> 
>return $dividend / $divisor;
>}
> 
> There is already a little discussion around the choice of order in the above 
> statement, the main take-aways and (my) perceived benefits are:
> 
>  - it keeps the intent nearest the left rail of the code (in 
> normal/common-ish coding standards)
> 
>  - it treats "return if" as a meta-keyword; if must follow return for the 
> statement to be a guard clause.  This also allows a person to more easily 
> discern "returns" from "return ifs" more easily since there is not an 
> arbitrary amount of code between them (for example if the return expression 
> were after return but before if).
> 
>  - it has the quality that optional parts are towards the end
> 
>  - is also has the quality that the : return_expression; is very symmetrical 
> to the way we demarcate the return type in method signatures
> "): return type {" for example.
> 
>  - has the quality of promoting single-line conditional returns
> 
> 
> # Finally
> 
> One might say this is unnecessary syntactic sugar, which is definitely 
> arguable. But we do have multiple ways of achieving this.
> 
> Of course all of these things should be discussed, I think sub-votes (should 
> this PR make it that far) could be considered.
> 
> The PR is located here:
> 
>  https://github.com/php/php-src/pull/5552
> 
> As mentioned, some discussion is happening there as well.
> 
> 
> Thanks!
> Ralph Schindler
> 
> 
> PS: since implementing the ::class feature 8 years ago, the addition of the 
> AST abstraction made this kind of syntactical change proof-of-concept so much 
> easier, bravo!

I'm in favor of language features that encourage defensive coding, so, I think 
the concept behind return-if is good, but your approach too limited.

I think a more general guard syntax would be better:

guard (some condition) else {
//code here must exit the parent block, or else an error is generated 
(at compile-time if possible)
}

This would allow for more and broader use cases: the code in the else clause 
could do any of return, continue, break, throw, exit, or maybe even goto, as 
appropriate to the condition and its parent block, which could be any 
functional block — a function, loop, if, else, try, or catch clause, or the 
"global" scope outside of a function or class definition. And, if you did 
return (as opposed to something else), you'd retain locality of 'return' and 
the return value, rather than separating it with the condition.

-John

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

Re: [PHP-DEV] [RFC] Named arguments

[John Bafford]

Hi Rowan,

> On May 5, 2020, at 16:47, Rowan Tommins  wrote:
> 
> Hi John,
> 
> On 05/05/2020 18:27, John Bafford wrote:
>> I very much do like the idea of named parameters, but I do not like the 
>> specific proposal in the linked RFC at all. I think that treating named 
>> parameters simply as syntactic sugar is not a good approach. If we're going 
>> to add named parameters, I think they should actually be significant in 
>> their own right. As such, please allow me to present an alternative.
>> 
>> I would propose the following opt-in mechanism, which would work by treating 
>> the parameter names as*part of the function name*. Doing it this way 
>> I_think_  should allow for no backwards compatibility issues with existing 
>> code and would especially give library authors full control over the naming 
>> and presentation of their APIs.
> 
> 
> I really like *some* of this proposal, but I think some of it is solving a 
> different problem.
> 
> 
> You mention in a later e-mail that you've been heavily inspired by Swift; 
> Swift in turn was inspired by Objective C, which was inspired by Smalltalk. 
> This is an important piece of history, because Smalltalk doesn't actually 
> have methods with named parameters; it has "keyword messages" whose 
> "selectors" are things like "indexOf:startingAt:". Swift makes them look more 
> familiar by keeping part of the name separate from what it calls "argument 
> labels", so a method might be called "indexOf(_:startingAt:)" or 
> "index(of:startingAt:)".

You're not wrong here, but, I think that's an (critical) implementation detail 
of Objective-C and Smalltalk that is not relevant here. Also, Swift does not 
use selectors or message passing, unless either interoperating with ObjC 
classes, or the code has explicitly opted-in. Normally, Swift function/method 
calls are statically determined at compile time in a way similar to C/C++.


> Although at a glance these look like named parameters, and they solve some of 
> the same problems, they're actually a fundamentally different concept.
> 
> They have some nice features:
> 
> * Method calls can be made to read like sentences
> * The external API of the function is kept separate from the internal 
> implementation
> * You can skip over default arguments by omitting their labels
> * Overloading what looks like one method, by having different methods whose 
> names start the same but have different "argument labels", may be appealing
> 
> But there are some crucial limitations:

I don't think any of your points are downsides to the proposal. A lot of these 
I think boil down to the conflict between, "as an API user, I should be able to 
do whatever I want", and, "as an API author, I have decided my API will be used 
like this". I generally side with the API author being specific on how their 
API will be used.


> * You can't call a method without using its labels; you'd need to have a 
> separate method with a similar name and no labels

If a function/method has labels, you're required to use them. Otherwise, you 
can't get the benefit of using them for name-based "overloading". For example, 
if you have the methods

function firstIndex(of: $element) : ?int
function firstIndex(where: callable $predicate) : ?int

You can't just call $collection->firstIndex($foo), because the compiler would 
have no idea which method it refers to. And while you _could_ have a function 
firstIndex($param) that tries to determine which specific method to call, but 
now you've turned a compile-time static call into a runtime check, and that 
might still not be sufficient, for example, if you have a collection of 
callables!

The labels are part of the method's name, which happen to be written inside the 
parenthesis. I just argue that both of those are more readable than either of 
these:

function firstIndexOfElement($elt) : ?int
function firstIndexMatchingPredicate(callable $predicate) : ?int

If I give my method a particular name, I expect users to call them as such. If 
the user doesn't like it, then they can wrap the class and provide their own 
alternate interface.


> * Similarly, it's up to the method's author to have versions with a mixture 
> of unlabelled and labelled parameters, so a call like "create('hello', 42, 
> locked: true)" is only possible if that specific variant is defined

As above: a method's author is under no compulsion to do so. If I define my API 
to be create('hello', fontSize: 42, locked: true), then that's how I expect my 
users to call it.


> * You can't use the labels in the "wrong" order, you have to know the order 
> they come in; so it doesn't solve the haystack/need

Re: [PHP-DEV] [RFC] Named arguments

[John Bafford]

On May 5, 2020, at 14:21, Nikita Popov  wrote:
> 
> Another is to allow specifying the public parameter name and the private
> parameter variable name separately, as is possible in Swift. This would
> allow changing "parameter" names arbitrarily, without breaking the public
> API. This would be a pretty direct counter to your concern, but I'm not
> really sure that your concern is important enough to warrant the additional
> weight in language complexity. I've never used Swift myself, so maybe this
> is actually awesome and I just don't know it.
> 
> Regards,
> Nikita

The proposal in my earlier email is very much inspired from Swift. I think 
having distinct outside and inside names helps greatly with creating expressive 
and readable APIs. The most expressive name for a thing might differ greatly 
between inside and outside contexts. Also, the name of a parameter as used by 
the inside of a function should be an implementation detail; there's no reason 
it should have to be exposed to the outside.

For example, Swift's Array has the following two methods (slightly simplified):

func firstIndex(of element: Element) -> Int?
func firstIndex(where predicate: (Element)  -> Bool) -> Int?

You call them like:

array.firstIndex(of: someElement)
array.firstIndex(where: { $0 == someElement })

From the outside, firstIndex(of: ...) is more readable than firstIndex(element: 
...) because it reads more like natural language. Same with firstIndex(where: 
...) vs. firstIndex(predicate: ...). On the inside, calling it "element" and 
"predicate" help you focus on what it _is_, without worrying about calling it 
something that also retains meaning to callers.

If you at some point decided to have a mass-renaming of "predicate" to "test", 
you could change that everywhere in your library without forcing any sort of 
change to users, because predicate is "on the inside". And both of them 
starting with 'firstIndex(' gives them a clear relationship; they generally do 
the same thing, just with a type of input.

With php currently, you would probably implement those as:

function firstIndexOfElement($element)
function firstIndexWithPredicate($predicate)

$collection->firstIndexOfElement($element);
$collection->firstIndexWithPredicate($someCallable);

But I think that's more wordy, and now you have either a BC break or need to 
add a new function if you decided to rename all instances of "predicate" to 
"test".

A more readable API might look like this:

$collection->firstIndex(of: $element);
$collection->firstIndex(where: $someCallback);

which is less typing, presuming your IDE didn't offer autocomplete for you 
anyway.

-John

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

Re: [PHP-DEV] [RFC] Named arguments

[John Bafford]

Hi Nikita,

> On May 5, 2020, at 09:51, Nikita Popov  wrote:
> 
> Hi internals,
> 
> I've recently started a thread on resurrecting the named arguments proposal
> (https://externals.io/message/109549), as this has come up tangentially in
> some recent discussions around attributes and around object ergonomics.
> 
> I've now updated the old proposal on this topic, and moved it back under
> discussion: https://wiki.php.net/rfc/named_params
> 
> Relative to the last time I've proposed this around PHP 5.6 times, I think
> we're technically in a much better spot now when it comes to the support
> for internal functions, thanks to the stubs work.
> 
> I think the recent acceptance of the attributes proposal also makes this a
> good time to bring it up again, as phpdoc annotations have historically had
> support for named arguments, and this will make migration to the
> language-provided attributes smoother.
> 
> Regards,
> Nikita


I very much do like the idea of named parameters, but I do not like the 
specific proposal in the linked RFC at all. I think that treating named 
parameters simply as syntactic sugar is not a good approach. If we're going to 
add named parameters, I think they should actually be significant in their own 
right. As such, please allow me to present an alternative.

I would propose the following opt-in mechanism, which would work by treating 
the parameter names as *part of the function name*. Doing it this way I _think_ 
should allow for no backwards compatibility issues with existing code and would 
especially give library authors full control over the naming and presentation 
of their APIs. Here is how it would work:

Let's start with an ordinary function:

function foo(int $a, int $b) : void {}

and then add named parameters:

function foo(a: int $a, b: int $b) : void {}

These are now two _completely different functions_. The first is named 'foo'. 
The second is named 'foo(a:b:)'. They can both coexist in the same namespace. 
This would solve two big classes of backwards compatibility issues.

First, adding the named-parameter function would not require any changes to any 
existing code. If the named-parameter function were to become the preferred 
version, then whatever library implements it could easily forward calls and add 
a deprecation warning to the old function:

function foo(int $a, int $b) : void { foo(a: $a, b: $b); }

Second, by having separate public and internal parameter names, it becomes 
possible to evolve APIs without breaking existing users. If we start from our 
original two functions above and decide to fix the poorly-named parameters, we 
could make these changes and continue to have backwards compatibility with all 
existing users:

function foo(hours: int $hours, minutes: int $minutes) : void {}
function foo(a: int $hours, b: int $minutes) { foo(hours: $hours, 
minutes: $minutes }
function foo($hours, $minutes) { foo(hours: $hours, minutes: $minutes }

Changing the external parameter name counts as changing the function's name, 
which means it's an entirely different function. (Which lets us also leave the 
old-named function there as a fallback.) Changing the internal parameter name 
has no effect to the outside, and can be changed at will. This also solves the 
problem with overloading: you can change the internal parameter names all you 
like, so long as you keep the external parameter name - which is part of your 
declared API.

Because the parameter names are part of the function name, you would *not* be 
able to pick and choose which parameter names you use. If the function declares 
parameter names, they must be used at the call site.

Parameters are also positional. foo(a:..., b: ...) and foo(b: ..., a: ...) are 
two completely different functions, by name. If you have foo(a:b:) defined, 
then you cannot call it as foo(b: ..., a: ...).

Both of these last two provisions are to eliminate ambiguity and create 
consistency in the call site. Otherwise we could easily wind up with confusion 
like in the implode and explode parameter orderings.

You could allow having nameless parameters by doing this:

function bar(_: int $one, two: int $two) {}
bar(1, two: 2);

The "nameless" parameters would still be explicitly named ("_"), but users 
would not have to provide that name at the call site. It would be permissible 
to mix named and unnamed parameters, though style guides want to discourage 
that as there's probably few use-cases where this makes sense:

function baz(holiday: string $name, _: string $date, color: string 
$color) {}
baz(holiday: 'Star Wars Day', 'May 4', color: 'purple');

There might be complexity around named and unnamed overlap with this special 
case:

function overlap($a, $b); //nominally named 'foo'
function overlap(_: $a, _: $b); //nominally named 'foo(_:_)'

In which case both functions would normally be called with the exact same 
syntax. 

Re: [PHP-DEV] Typed array properties V2

[John Bafford]

> On Jan 24, 2020, at 14:27, Mike Schinkel  wrote:
> 
> Thus far we have discussed that implementation of type checking for arrays 
> would be too costly from a performance perspective and that there is no good 
> solution that is not extremely complicated to implement.
> 
> Given that, can we consider an alternative?  
> 
> ALLOW the use of a syntax for typed arrays — whether it be type[] or [type] — 
> but only validate that it is an array and that the "type" is in fact a type, 
> but don't actually validate that each element is the correct type. 
> 
> This would allow those of us who want to start documenting specific usage 
> using type hints to be able to do so instead of what we currently have to do 
> is PHPDoc one way and type hint with "array."  It would also allow IDEs like 
> PhpStorm to add support.  
> 
> Is this something the PHP community would consider?
> 
> -Mike


My opinion is that if you're going to declare the type of a variable, you have 
to have some way of enforcing that the type _really_ is what you say it is. 
Otherwise, the type information is basically a lie, and you're much better off 
without it. If PHP's type system can't or won't enforce the type fully as 
declared, then it's much better to have phpdocs that assert what the type 
"really" is, like we do now. 

I have some ideas on what might be reasonably performant array type 
enforcement, but having not fully read the thread, I'll keep that to myself 
until I have a chance to see that I have anything that's actually novel.

-John

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

Re: [PHP-DEV] Typed array properties V2

[John Bafford]

> On Jan 19, 2020, at 19:53, Mike Schinkel  wrote:
> 
> P.S.  There was also the mention by Levi Morrison that the type[] syntax was 
> a poor one because of ambiguity between (?int)[] or ?(int[]).  I would argue 
> that the latter would likely occur orders of magnitude more often than the 
> former, so I would argue that ?int[] should interpret as ?(int[]), and if 
> they want (?int)[] then the developer should use parentheses.

As a thought, perhaps the syntax '[Type]' for an array of Type. That way, you 
could write ?[int], or [?int], or even ?[?int] and there would be no ambiguity, 
and no need for parentheses since the array brackets would serve that purpose.

If we also wanted to allow typing array keys, this syntax could be extended to 
[string : Type] and [int: Type], and it would continue to remain unambiguous, 
even with nested arrays, and with using a more similar syntax than the docblock 
syntax array. (It might also be reasonable to support both 
variants as aliases of each other.)

Both of these are the syntax Swift uses for arrays and dictionaries, so the 
syntax has precedence from another language. Swift also supports both syntaxes 
as described above ([KeyType : ValueType] is exactly the same as 
Dictionary), but the shorter bracket syntax is preferred 
for readability.

-John

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

Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct

[John Bafford]

Chase,

On Jan 22, 2016, at 13:15, Chase Peeler  wrote:
> 
> 1.) I think everyone already knows how to be an adult. The fact that
> sometimes we don't act in a civil manner isn't because we don't have
> something telling us what civil behavior entails. Putting it in writing
> might make us feel good, but it isn't going to change how anyone behaves.
> Putting it in writing is necessary only if you intended to have a way to
> enforce it - which requires some form of punitive measures for those that
> don't, as well as a way to determine if someone violated them.

I disagree with part of your assertion here.

Having a written down statement of expected behavior is useful from the 
standpoint that it makes it much easier for others to point at and say, “look, 
you’re out of line, knock it off”.

For example: where I live, it’s local regulation that in a public park, dogs 
must be on leashes. (Doesn’t matter how big, or small, or how friendly, or how 
well-behaved, *all* dogs *must* be on leashes at *all* times, except where 
otherwise specifically allowed, such as in dog parks.) Occasionally, some 
people forget (or ignore, or don’t know about) that restriction (or forget 
they’re not in a dog park). It’s a whole lot easier to call out the 
misguided/accidental/bad behavior when someone can point at the posted sign and 
say, “hey, please leash your dog; unleashed dogs aren’t allowed here,” because 
then it can’t be taken only as someone complaining just to complain; instead, 
it’s someone pointing out an actual, written, violation of the rules, backed up 
by a six foot tall sign.

Having the sign also serves the purpose of reminding everyone (good and bad 
citizens alike) what the rules are so they can be more confident in calling out 
bad actors. It helps prevent or improve either of these two scenarios: “Hmm… I 
think dogs must be leashed… but I can’t remember? Probably shouldn’t say 
anything just in case I’m wrong…”, or, “wow, that’s a pretty unfriendly person 
and their dog. I better get the number from that sign so I can call the parks 
department and report them."

Putting a code of conduct, or contributor guidelines, or whatever you want to 
call it *in writing* (and regularly posting them to the mailing list as a 
reminder) serves exactly the same purpose as that sign at the park: gently 
remind everyone what the rules are; provide something clearly in writing that 
everyone can look at and understand; and provide contact information for 
questions and complaints. Written guidelines *absolutely will* bring about a 
change in how people behave: it may not immediately deter bad actors, but it 
will empower the neutral and good actors in bringing about censure and 
rehabilitation of those not acting in the public interest.

-John


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

[PHP-DEV] PR #1723 - fix for crash in mysqli_connect

[John Bafford]

Hi all,

Can someone take a look at this PR to fix a crash with mysqli_connect arising 
with a mysqlnd refactor in e81ecc80c in master from November:

https://github.com/php/php-src/pull/1723

When attempting to mysqlI_connect(‘localhost’, ‘user’, ‘pass), the 
mysqlnd_conn_data::get_scheme introduced in e81ecc80c was no longer able to 
update the socket_or_pipe in mysqlnd_conn_data::connect  with the socket 
filename in the event hostname == localhost. This causes a crash in 
mysqlnd_conn_data::connect when an attempt is made to duplicate the string to 
store it in conn->unix_socket.s.

Thanks!

-John


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

Re: [PHP-DEV] Back to the code (was Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct))

[John Bafford]

Adam, Sascha,

> On Jan 13, 2016, at 08:53, Adam Howard  wrote:
> 
> Well, I'm glad someone is in agreement.  I really wish we'd get back to the 
> actual code.  Because if not, I do think perhaps PHP Internals as outlived 
> the email format and should migrate to a forum format.  I think I and many 
> others did not subscribe to a mailing list for this type of argument and at 
> this point it is becoming hard to follow, assume you were interested in it.
> 
> This little link http://www.php.net/unsub.php to unsubscribe is the last 
> report, but if this all we're going to keep arguing about, it sure isn't 
> going to encourage newbies, let alone long-timers such as myself.
> 
> On Wed, Jan 13, 2016 at 1:26 AM, Sascha Schumann 
>  wrote:
> > On January 12, 2016 at 7:05 PM Adam Howard  wrote:
> >
> > Can we please move on past this and get back to actual code.  Because if
> > not, perhaps PHP Internals has outgrown the email format and should migrate
> > to a forum type format.
> 
> Agreed.

This is almost exactly the point I was trying to make.

There is a serious problem with the conversation on internals, and the 
immediate reaction is, “there’s no problem, this is a distraction, stop talking 
about this and talk about something else”.

Even if you didn’t *mean* that, that’s what was heard.


In one email, and one “me too” follow-up you’ve:

* attempted to silence an important discussion
* suggested that that the opinion held (and François’ question) is not worthy 
of discussion
* distracted the discussion with an unusable suggestion [* see below]
* provided nothing constructive to help actually solve the problem
* reinforced the notion that nothing is wrong and everything is fine.

THIS is toxic internals.


Let me elaborate on the third point, particularly the distracted and unusable 
bits:

You make the assertion that this conversation is an indication that 
php-internals has outgrown email and should migrate platforms. And you propose 
an alternative.

But you don’t explain *why* you think that this conversation has outgrown 
email, and even more importantly, you don’t you don’t actually explain *why* a 
forum format would be an improvement.

I’m not saying that a forum *couldn’t* be an improvement. But without you 
giving any supporting argument, you’ve given nothing concrete that anyone can 
have a discussion about. It’s not actively helping to solve the problem. It’s 
just more noise that serves to make people think their comments don’t matter. 
(For the record: I don’t like forums. And I really don’t see how forums would 
solve the culture problem. But me saying that, and only that, is just as 
constructive as you saying only that we should switch to one.)

So, your suggestion is unusable, because it provides nothing constructive or 
actionable; and it is a distraction because the platform we use to talk is 
*entirely* irrelevant to how people hold conversations on that platform, and 
rather than discussing the problem, you try to talk about something completely 
unrelated instead.


I didn’t sign up for internals looking to deal with this either. But there is a 
problem, and it is keeping me from actually contributing code. And I’ve been 
sitting on the sidelines here for a *long* time. I’m trying to make it so that 
newbies feel welcome to contribute. I’m trying to make it so that the 
old-timers who have reduced their participation feel like they can come back 
and be productive again.

I would *love* to talk about code now. I wish we didn’t have to talk about 
this. But silencing the conversation and wishing the problem away doesn’t fix 
the the giant elephpant in the room. It just *makes it worse*.

-John


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

[PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

[John Bafford]

Stas,

On Jan 11, 2016, at 23:24, Stanislav Malyshev  wrote:
> 
> Hi!
> 
>> This is yet another example of the toxic internals problem.
>> Regardless of one's views on the CoC proposal, the conduct of
>> php-internals as a whole has been reprehensible.
> 
> What in your opinion was reprehensive, could you explain?

Let me reiterate that the question that was posed, and which I am answering is, 
“Why do people avoid internals?” and “Does internals want to attract newcomers?”

Let me make very clear:

* I am talking about *perception*. In this context, perception is way 
more important than reality. Because to answer those two questions, perception 
is the key.

* I am not indicting any one person or event or thing said in 
particular. I am indicting the *whole of internals as a group* on its conduct. 
(And so my comments in general should be taken in that light, and not as finger 
pointing at any one person/event/thing said in particular.)


What was reprehensible is not just the comments that were made, *how* they were 
made, and the *response* to them. It’s that it’s a *persistent pattern of 
behavior*.

It’s not JUST the CoC RFC thread. It’s the STH thread. And every other thread 
like it.

It’s every time the conversation degenerates to nastiness.

It’s every time someone threatens that something needs to be their way or 
they'll take their ball and go home.

It’s every time someone takes their ball and goes home, whether they threatened 
to, or because they felt they had to.

It’s every time someone makes wild accusations and doesn’t take the time to 
back up their arguments or provide something constructive to the discussion.

It’s every time someone nitpicks a proposal to death, conveniently (and/or 
intentionally) missing the point, and keeps doing it in an attempt to kill the 
proposal by attrition, rather than sound reasoning.

It’s every time that happens and people don’t shut up and admit that their 
opinion is divergent from consensus, and that sometimes we have to agree to 
disagree, and work towards making the whole better.

It’s every time a proposal comes up and people actively try to destroy it 
rather than actively making it better *even if they don’t agree with it*.

Toxic internals is not just bad words. It’s *all of the above*.


Every so often, there is a conversation in which someone says things in such a 
caustic manner (or just plain caustic things), and the general reaction beyond 
“(well, maybe you should tone that done a little bit)” is apologetically “well, 
they’re not that bad in person”, or, “they’re not a bad person”, or “you just 
have to know them”, or silent acceptance. And I mean caustic in both the 
corrosive/corroding/abrasive *and* sarcastic/cutting/biting meanings. It goes 
way beyond cute or funny. The level of vitrol is astounding.

And it is *not* acceptable.



I *know* the people on internals are good people. (I presume. I don’t know you 
all personally. But let’s take as given.) I *know* everyone here is smart, and 
hard working, and talented. But everyone put together in this pot called 
php-internals has produced something pretty foul. At least, it certainly smells 
that way.

I understand that we’re a passionate people, and that sometimes things get out 
of hand. But wow, when it gets out of hand, it really goes through the roof and 
people can’t help themselves but pile on when the appropriate response is to 
call a time out, sit back down in their chairs, meditate on .


Another part of the problem is the constant gaslighting and Sea-Lioning (as 
Anthony puts it). I’ve watched many conversations run around in circles, with 
everyone making the same points over and over again, the tone deteriorating 
over time (or starting out deteriorated). There’s always someone who seems 
intent on intentionally misunderstanding the situation. A lot of talk and 
nothing really said.


Again, a reminder: perception is more important than reality. Whether people 
like the way internals is, or even if they think that it’s simply “ok” or 
“acceptable”, looking at internals from the sidelines, the lot of us look 
brain-damaged, and not in a warm fuzzy endearing way, but in a psycopath way.

It doesn’t matter that everyone here is a decent person. I don’t think that 
anyone here is a psycopath. But internals itself gives that vibe. I’m sure it 
doesn’t mean to, but it does. Internals is *not* a nice group to work with. If 
internals were my client, I’d fire them. If it were my boss, I’d quit and go 
somewhere else. (Again: *internals, the group*, and not any individual person 
on this list.)




>> And *every* time I start to think, "ok, I'm finally going to dust off
>> those old patches and write some RFCs" this shit happens, and I
>> reconsider and go back to lurk mode because I have no interest in
>> participating in conversations about facists, whether real or
>> imagined.
> 
> Precisely one person mentioned anything about "fascists", 

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

[John Bafford]

Sascha,

> On Jan 12, 2016, at 11:17, Sascha Schumann  
> wrote:
> 
> Hi John,
> 
>> And it is *not* acceptable.
> 
> May I ask who put you in charge to determine whether something is "acceptable"
> or "reprehensible”?

*I* avoid internals because *I* believe the conduct here is reprehensible, and 
not acceptable.

So in the context of the questions “Why do people avoid internals?” and “Does 
internals want to attract newcomers?”, the only questions which I am attempting 
to answer, and in terms of *my own personal view of internals as a whole* in 
response to those questions, I did, because it is strictly my opinion.

You [= the reader, not Sascha specifically] may or may not agree. That is fine. 
You may think that that there is a problem, but it doesn’t rise to the level of 
being reprehensive. That’s fine too. Maybe it does, maybe it doesn’t. But this 
is *my* opinion, *my* answer to the question at hand, and it is up to you, and 
everyone else, to make their own decision as to whether there actually is a 
problem on internals. I think there is, and I’ve outlined what I see to be the 
problem. Someone else can answer the questions differently. They may not think 
internals’ conduct is reprehensible. They may think the conduct is acceptable. 
That debate can be had, but it doesn’t change my perception.

-John


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

[PHP-DEV] Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

[John Bafford]

[Apologies for the re-post; I’m re-sending this with a new subject because it’s 
really not about the CoC RFC.]

> On Jan 11, 2016, at 19:40, François Laupretre  wrote:
> 
> If we want to deal with the reasons why people avoid internals, the let's go 
> and analyze the problem first ? I will start asking whether we really want to 
> attract newcomers. The question may sound ridiculous but I think we don't, 
> mostly because most people here see newcomers as just a source of annoyment 
> and silly questions/RFCs. Additional evidence shows that we never did much 
> effort to help integrate newcomers.
> 
> So, the tone on the list is, IMO, just a small part of the problem. As long 
> as there's no consensus on whether we want to attract newcomers and the 
> effort we're ready to do to integrate them, discussing about the details of a 
> CoC seems a bit prematurate to me.


I agree with this 100%.

This is yet another example of the toxic internals problem. Regardless of one's 
views on the CoC proposal, the conduct of php-internals as a whole has been 
reprehensible.

Whether anyone agrees with that statement or not is almost besides the point. 
Internals has a *reputation* for being toxic, and whether or not that 
reputation is justified, *it exists*, and internals is not doing anything to 
counter that reputation. Certainly not with the CoC discussion.

I have watched internals for probably ten years now. I have *never* gotten the 
impression that internals was actually seriously interested in cultivating 
newcomers. Lip service is paid from time to time, but at the end of the day, 
nothing ever changes.

So let's say, hypothetically, internals actually, seriously, wants newcomers.

I've used C since 1997, PHP since 1999, come from a CS background, and PHP is 
my favorite language (well, maybe it's a tie with Objective-C). At least, it's 
the language I use most often, so I have a vested interest in helping it get 
better. I am exactly the sort of person internals should be courting to join 
the "team".

And *every* time I start to think, "ok, I'm finally going to dust off those old 
patches and write some RFCs" this shit happens, and I reconsider and go back to 
lurk mode because I have no interest in participating in conversations about 
facists, whether real or imagined.

I've got one RFC under discussion, and another one in draft that should be 
ready for discussion soon. Hell, I had been collecting emails for a few weeks 
and was just about to start work on (what I had hoped would be an ongoing 
series of) a weekly summary of internals (similar to what Pascal Martin had 
been doing in 2014) as an excuse to actually read all of internals to help wrap 
my head around what was actually going on from a tech perspective. Then the CoC 
thing blows up, and it's all so disheartening. Makes me question whether 
putting in the effort was worth it, and well, you can forget about anyone 
trying to write an impartial summary of the CoC discussion.

And that's just internals. There's also apparently twitter and reddit flamewars 
and namecalling going on that I'm just as happy to know nothing about.

This is getting a bit ranty. But internals deserves it. You all may be great 
programmers, but in terms of making people *want* to work on php-src, you're 
shitty salespeople.

The reputation for internals being toxic surely bleeds over to everyone else 
who knocks PHP as being a shitty language. Only now, they get to say, "what a 
bunch of amateurs, the language devs can't even discuss a code of conduct 
without calling each other nazis".

Stop the nonsense. Get better, grow up, treat each other with respect, and act 
like the adults you are. I'd like to work with you all, but you make it dammned 
hard to want to.

-John

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[John Bafford]

> On Jan 11, 2016, at 19:40, François Laupretre  wrote:
> 
> If we want to deal with the reasons why people avoid internals, the let's go 
> and analyze the problem first ? I will start asking whether we really want to 
> attract newcomers. The question may sound ridiculous but I think we don't, 
> mostly because most people here see newcomers as just a source of annoyment 
> and silly questions/RFCs. Additional evidence shows that we never did much 
> effort to help integrate newcomers.
> 
> So, the tone on the list is, IMO, just a small part of the problem. As long 
> as there's no consensus on whether we want to attract newcomers and the 
> effort we're ready to do to integrate them, discussing about the details of a 
> CoC seems a bit prematurate to me.


I agree with this 100%.

This is yet another example of the toxic internals problem. Regardless of one's 
views on the CoC proposal, the conduct of php-internals as a whole has been 
reprehensible.

Whether anyone agrees with that statement or not is almost besides the point. 
Internals has a *reputation* for being toxic, and whether or not that 
reputation is justified, *it exists*, and internals is not doing anything to 
counter that reputation. Certainly not with the CoC discussion.

I have watched internals for probably ten years now. I have *never* gotten the 
impression that internals was actually seriously interested in cultivating 
newcomers. Lip service is paid from time to time, but at the end of the day, 
nothing ever changes.

So let's say, hypothetically, internals actually, seriously, wants newcomers.

I've used C since 1997, PHP since 1999, come from a CS background, and PHP is 
my favorite language (well, maybe it's a tie with Objective-C). At least, it's 
the language I use most often, so I have a vested interest in helping it get 
better. I am exactly the sort of person internals should be courting to join 
the "team".

And *every* time I start to think, "ok, I'm finally going to dust off those old 
patches and write some RFCs" this shit happens, and I reconsider and go back to 
lurk mode because I have no interest in participating in conversations about 
facists, whether real or imagined.

I've got one RFC under discussion, and another one in draft that should be 
ready for discussion soon. Hell, I had been collecting emails for a few weeks 
and was just about to start work on (what I had hoped would be an ongoing 
series of) a weekly summary of internals (similar to what Pascal Martin had 
been doing in 2014) as an excuse to actually read all of internals to help wrap 
my head around what was actually going on from a tech perspective. Then the CoC 
thing blows up, and it's all so disheartening. Makes me question whether 
putting in the effort was worth it, and well, you can forget about anyone 
trying to write an impartial summary of the CoC discussion.

And that's just internals. There's also apparently twitter and reddit flamewars 
and namecalling going on that I'm just as happy to know nothing about.

This is getting a bit ranty. But internals deserves it. You all may be great 
programmers, but in terms of making people *want* to work on php-src, you're 
shitty salespeople.

The reputation for internals being toxic surely bleeds over to everyone else 
who knocks PHP as being a shitty language. Only now, they get to say, "what a 
bunch of amateurs, the language devs can't even discuss a code of conduct 
without calling each other nazis".

Stop the nonsense. Get better, grow up, treat each other with respect, and act 
like the adults you are. I'd like to work with you all, but you make it dammned 
hard to want to.

-John


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

Re: [PHP-DEV] Re: [RFC] array_key_(first|last|index) functions proposal

[John Bafford]

Hi Andrea,

> On Jan 4, 2016, at 12:05, Andrea Faulds <a...@ajf.me> wrote:
> 
> Hi John,
> 
> John Bafford wrote:
>> Happy New Year, everyone!
>> 
>> I’d like to present the first new PHP RFC for this year, a proposal to add 
>> functions to easily get the first, last, or an arbitrary key (and value) by 
>> index from an array, taking advantage of PHP’s property that arrays are 
>> ordered maps.
>> 
>> RFC: https://wiki.php.net/rfc/array_key_first_last_index
>> PR: https://github.com/php/php-src/pull/347
> 
> How often would such functions be useful? Perhaps they fill a gap, but I'm 
> not sure if it's one that needs filling. array_key_first and array_key_last 
> can already be accomplished in two or so lines of code (four if you make a 
> function), and array_key_index can be implemented in a few lines with a 
> foreach() loop and a counter.

array_key_first() and array_key_last() can’t be implemented in userspace and 
maintain all three of fast, immutable, and doesn’t-look-weird.

The best you could do for array_key_first() is:

function array_key_first($arr) {
foreach($arr as $k => $v)
return $k;

return null;
}

Which already looks kind of weird. For array_key_last, your best bet is

function array_key_last($arr) {
$k = null;  
foreach($arr as $k => $v)
;
//Rely on the fall-through of $k from the last iteration
return $k;
}

which looks even weirder

or 

function array_key_last($arr) {
$keys = array_keys($arr);
if($cnt = count($keys))
return $keys[$cnt - 1];

return null;
}

Which adds the overhead of array_keys() iterating over the array and 
duplicating *all* of the array’s keys just to retrieve one.

Any solution that uses reset() + key() or end() + key() mutates the array, 
which means duplicating it if you pass it into a function. This takes a 
non-trivial time if you have a large array.


> array_key_first and array_key_last seem mostly harmless, at least. I'm not 
> sure the same can be said for array_key_index, since it has O(n) complexity. 
> I worry that it might end up used by people who think it is more efficient 
> than iterating through an array, even though it is not. I would rather we not 
> include this specific function, and avoid potentially disguising the time 
> complexity of key lookup, especially as I can't think of a good use-case for 
> it. As for array_key_first and array_key_last, well, maybe they're useful, I 
> have no strong opinion on them. They might be handy to get the first and last 
> key of an array without moving the internal pointer, so who knows, maybe we 
> should add them.

I’ll admit that array_key_index() could be easily abused. If you need to use it 
more than a few times on a particular array, unless you’ve got a huge array and 
need to keep memory use constrained, you’re probably better off just calling 
array_keys() and using an index into the result. This would need to be included 
in the documentation as a use case caveat, though it wouldn’t be surprising if 
people ignored the warning and used it incorrectly anyway.

The reason array_key_index() is included in the RFC is because it kind of fell 
out of the original implementation and since it’s kind of useful, for a limited 
set of problems, I kept it in. It’s really more of a special-case tool with 
(very) limited general use, but it is a substantial improvement over the 
alternatives if you really do it need.

My primary goal with this RFC is array_key_first() and array_key_last(), so I 
would not be against having array_key_index() be a separate voting choice, if 
that would make people more comfortable.


> Thanks.
> -- 
> Andrea Faulds
> https://ajf.me/


-John


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

Re: [PHP-DEV] RFC Operator Overloading in Userspace

[John Bafford]

Hi Sara,

On Jan 2, 2016, at 21:14, Sara Golemon  wrote:
> 
> Patricio Tarantino has asked me to help him propose Operator
> Overloading in PHP 7.1 (based in part on my operator extension in
> PECL).  I think we can expose this to usespace as magic methods with
> very little overhead (the runtime check and dispatch is already there,
> after all).
> 
> I do think that the "Future Expansion" section bears following through
> with as well, but the basic set of methods already hooked for GMP
> would be a nice start.
> 
> https://wiki.php.net/rfc/operator-overloading
> 
> -Sara


While I don’t necessarily think adding operator overloading is a great idea, I 
think if it’s to be done, we could do better. I’d offer two suggestions:

1) rather than the list of magic function names, use the actual operators 
themselves
> function ^($value)

or
> function operator <<($value)


This way, new magic methods don’t have to be created in the event we created 
new operators later. (Unlikely, I know.)

To handle ambiguity between prefix/postfix/infix operators, you could use 
something like:
> function prefix -($value)

> function infix -($left, $right)
> function postfix ++($value)


This would also address an issue in the proposal as written: __add and __sub 
don’t handle the ambiguity of prefix + and - operators.

Bishop Bettini suggests:
> public function __overload(string $operator, object $rhs = null); // $rhs === 
> null iff op is unary


but you really need separate functions (or an additional parameter) to handle 
that case. You can’t only pass in null because then you can’t disambiguate 
between $foo - null and -$foo.


2) I think we should take a look at Swift’s operator definition mechanism. 
Besides just allowing for operator overloading, Swift also allows you to 
specify entirely custom operators. For example (from the Swift Programming 
Language book, Language Guide, Advanced Operators chapter):

> “New operators are declared at a global level using the operator keyword, and 
> are marked with the prefix, infix or postfix modifiers:
> 
>> prefix operator +++ {}
> 
> The example above defines a new prefix operator called +++. This operator 
> does not have an existing meaning in Swift, and so it is given its own custom 
> meaning below in the specific context of working with Vector2D instances. For 
> the purposes of this example, +++ is treated as a new “prefix doubling 
> incrementer” operator. It doubles the x and y values of a Vector2D instance, 
> by adding the vector to itself with the addition assignment operator defined 
> earlier:
> 
>> prefix func +++ (inout vector: Vector2D) -> Vector2D {
>> vector += vector
>> return vector
>> }”

> “The following example defines a new custom infix operator called +-, with 
> left associativity and a precedence of 140:”
> 
>> “infix operator +- { associativity left precedence 140 }
>> func +- (left: Vector2D, right: Vector2D) -> Vector2D {
>> return Vector2D(x: left.x + right.x, y: left.y - right.y)
>> }”

Operators can be defined as prefix, infix, or postfix. Infix operators can 
specify associativity (left, right, or none (default)) and precedence. Swift 
limits the first character of an operator is limited to one from a set of 
typical operator symbols and a set of unicode characters, so you can’t create 
or overload operators using arbitrary ascii characters.

In PHP, we might imagine this example to look like:

> //in global scope
> operator infix +- associativity(left) precedence(140);
> function +-($left, $right) { … }

In Swift, operator definitions and overloads are done in on a global basis (and 
multiple definitions are resolved appropriately with Swift’s type system). This 
makes sense for Swift, but it would be more difficult for PHP, given PHP’s more 
flexible type system. I’m unclear what the best approach is to handle 
typehints, which in this case are more part of the operator functions logic 
name than just run-time limitations on parameters.

The major problem I see with this, besides the parser complexity it would 
entail, is that it would make static analysis that much harder, and you wind up 
with PHP code that can’t actually compile unless the operator definitions are 
loaded.

-John


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

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

[John Bafford]

> On Jan 1, 2016, at 15:20, Johannes Schlüter  wrote:
> 
> On Fri, 2016-01-01 at 13:28 -0500, Bishop Bettini wrote:
>> Hi, and happy New Year!
>> 
>> Now that the big push for PHP 7 is done, I'd like to revive earlier
>> discussions
>> 
>> on the *GitHub PR triage team* RFC .
> 
> ... and we don't have the issue with GitHub only, but also with
> bugs.php.net. But frankly I don't see the need for the RFC. This simply
> needs people to do the work. Anybody can leave comments and pester
> committers. Everybody with php.net account additionally can close bus
> and prs and assign bug issues.
> 
> Even if there is an RFC those volunteers are needed and could run away
> any time. 
> 
> So if you have the spare time simply start! Be brave!

I think the particular advantage of having an RFC (or if not an RFC, a document 
somewhere describing the contents of the RFC) is so that there’s a framework 
for the PHP project saying, “this is a desired thing we’d like to have as part 
of our normal process”, and in the event the people working on it step aside 
from lack of time, it provides a much easier way of getting someone else to 
pick up the mantle, since there’s already a document written describing what we 
want to have happen.

At the least, this is a request for comments, even if it doesn’t actually 
require a vote, and there didn’t really seem to be a better place to put the 
document at the time.

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


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

[PHP-DEV] [RFC] array_key_(first|last|index) functions proposal

[John Bafford]

Happy New Year, everyone!

I’d like to present the first new PHP RFC for this year, a proposal to add 
functions to easily get the first, last, or an arbitrary key (and value) by 
index from an array, taking advantage of PHP’s property that arrays are ordered 
maps.

RFC: https://wiki.php.net/rfc/array_key_first_last_index
PR: https://github.com/php/php-src/pull/347

Thanks,

-John


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

Re: [PHP-DEV] [RFC] array_key_(first|last|index) functions proposal

[John Bafford]

> On Jan 1, 2016, at 16:38, Bishop Bettini <bis...@php.net> wrote:
> 
> On Fri, Jan 1, 2016 at 3:44 PM, John Bafford <jbaff...@zort.net> wrote:
> Happy New Year, everyone!
> 
> I’d like to present the first new PHP RFC for this year, a proposal to add 
> functions to easily get the first, last, or an arbitrary key (and value) by 
> index from an array, taking advantage of PHP’s property that arrays are 
> ordered maps.
> 
> Thanks for submitting this RFC!  I am +1, with one quibble: obtaining the 
> value by reference seems non-sequitur to the function itself and PHP in 
> general.  IOW, this seems more PHPesque to me:
> 
> // get the next to last value
> $key = array_key_index($arr, -2);
> $val = $arr[$key];
> 
> Sincerely,
> bishop

While relatively rare for PHP, these aren't the only functions that have an 
optional second return value by reference. (preg_match, preg_replace, 
str_replace, among others.)

I agree that that’s a bit unusual in terms of PHP, but, if you actually need 
both the key and the value, this way you can do it in one call, rather than 
having to access the array and pull the value out of it separately. The C code 
already has a reference to the hashtable bucket, so returning the value if it’s 
needed is trivial.

-John


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

[PHP-DEV] Re: [RFC] GitHub Pull Requests Triage Team

[John Bafford]

Hi Bishop,

> On Jan 1, 2016, at 13:28, Bishop Bettini  wrote:
> 
> Hi, and happy New Year!
> 
> Now that the big push for PHP 7 is done, I'd like to revive earlier 
> discussions on the GitHub PR triage team RFC.
> 

Thanks for poking me about this. When I originally proposed the PR triage team 
after Zendcon 2014, I expected to have some free time to actually take charge 
of that proposed team. That free time unfortunately didn’t actually materialize 
until now, though. (Also, I have two other RFCs I’ll be proposing shortly.)

If people are interested in the PR triage team actually being a thing, then I’m 
happy to organize the effort and we can go through the PR backlog in an 
organized fashion and figure out what’s actually there.

I think when I brought this up before, the major open discussion point before 
the thread died was what period of time constituted long enough for closing a 
waiting-on-submitter PR. 2 weeks is probably too short, but it seemed a 
reasonable minimum and something had to go into the RFC. I think 4 weeks is 
probably a better place to start.

There was also some discussion on integration with bugs.php.net, and 
https://qa.php.net/pulls/ was mentioned, which seemed to be working until I 
started poking at it to see what it did, and now it’s not displaying anything. 
(oops!)

Also, there was the thought that it didn’t actually require an approved RFC to 
do, just people actually doing the work. (Which is probably true, but I created 
the RFC so as to have some ground rules for what said team’s responsibility 
would be.)


> A year ago, there were 180 open PR.  Today there are 281.  Most new PR are 
> labelled and better organized, but many dead/defunct/zombie/unloved PR 
> remain. I'm not aware of any process to handle those dead PR, and this RFC 
> seemed to address that problem with its three-part objectives:
>   • label PR appropriately,
>   • send a weekly "action list" summarizing pending PR, and
>   • ensure PR submitters keep their PR up to date, or close PR 
> accordingly.
> As I read the RFC, the team will not merge PR or hold RM responsibilities. 
> Instead, the team facilitates PR merging by keeping the PR list organized and 
> ready to act upon.

As written, that’s correct, though one of the follow-on proposals I intended to 
make after the team actually got established and was shown to be actually 
helping would be to ask for permission to merge trivial and obviously correct 
PRs (e.g. typo fixes or new/improved tests) since there’d be low risk of 
problems and allowing for a fast turn-around trivial things like that might 
help make it easier to include new people in the project, since those are the 
sort of low-hanging fruit that new devs often start with.


> Thoughts?
> 
> Thanks,
> bishop

-John


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

Re: [PHP-DEV] [VOTE] Void Return Type RFC

[John Bafford]

There are two particular semantic advantages of void functions I’m not sure 
have been brought up.


A function that always throws an exception can’t have a return value (and 
checking for one is also semantically and logically incorrect). Since such a 
function won’t ever return by normal means, the caller can't ever receive or 
inspect a return value.


A class of functions never return. That is, they always do one of
* infinite loop
* exit();
* pcntl_exec() or exit();
* terminate the process (e.g. trigger SIGKILL or other fatal signal to 
its pid)
* terminate the thread (e.g. pecl pthreads Thread->kill())  
* (There isn’t actually a facility for doing a setjmp/longjmp from 
userspace php, is there?)
* otherwise somehow prevent a return to parent scope

In this case, similar to the function that always throws, testing the return 
value is an error. The function *can’t* return, so there should never be 
anything to test. (And thus, testing its return value is a semantic error, 
which also implies a logic error because the caller is making an invalid 
assumption).


As an aside: if functions can somehow be annotated as no-return, static 
analysis tools could even flag code following said function calls as dead and 
warn about the existence of unreachable code. Wether PHP should add a noreturn 
keyword, or if a docblock annotation of a noreturn property should be 
“standardized" is a discussion for another time.


Originally coming from a C background, I’ve always appreciated that PHP 
functions always had a return value (even if null), because it allowed writing 
code such as this:

function method() {
// … preprocess ..
$return = parent::method();
// … postprocess ...
return $return;
}

without needing to know to whether the parent method actually returned anything 
or not (and working seamlessly in the case that the parent method changed what 
it was returning).


Given the above, and the fact that changing types on parent functions are going 
to force a change to child functions anyways, potentially the following three 
cases could be allowed:

function func() : void { return someOtherVoidFunc(); }

function method() : void {
// … preprocess ..
$return = parent::method(); //or possibly, some other void function
// … postprocess ...
return $return;
}

$variableNeverRead = voidFunc();

That is: allow “void” to be a write-only variable type, and trigger an error 
only if anything actually attempts to do any sort of operation on its value (as 
in, you can’t even inspect it to see if it’s void or not). Attempting to assign 
into a reference should probably fail immediately.

While I’d kind of like to see that, I’m not really sold on it since if the 
parent/called function’s prototype changes, the child/caller is going to have 
to change anyway (to account for the types of return values changing), so 
limiting that change to only the return type and not also the return itself is 
a potentially dubious win given the potential technical complexity involved in 
implementing this.

Thoughts?

-John

> On Oct 30, 2015, at 04:38, Chris Riley  wrote:
> 
> Hi,
> 
> I'm still not sure why we are using void as the return type and not null.
> Null matches behaviour, void just adds another keyword without value.
> 
> ~C
> 
> On 30 October 2015 at 04:33, Rasmus Lerdorf  wrote:
> 
>> On 10/29/2015 08:55 PM, Stanislav Malyshev wrote:
>>> Hi!
>>> 
 "void" or "null" as return type would give a 100% guarantee that every
>> possible
 implementation of a given interface won't return any random value. Then
>> it would
 make no difference if the returned value is being used or not, as it
 would always
 be null.
 
 So, it obviously solves the problem presented. There's not much to
>> dismiss here.
>>> 
>>> That's what I am having issue with. I don't see the case where such
>>> guarantee is useful. If you're not using the return value, why do you
>>> care if it's always null or sometimes null and sometimes baloney
>>> sandwich? If you need always null, you have it: null. You don't need to
>>> use return value of a function for it.
>> 
>> I agree with you Stas, but I still voted yes on this RFC as I don't see
>> the harm in having it. It is more of a hint for the compiler/static
>> analyzers for them to spew warnings/errors than it is a useful feature
>> at runtime. Enough people consider it a missing check mark on the
>> feature list for it to be added.
>> 
>> -Rasmus
>> 
>> 


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

Re: [PHP-DEV] Let's discuss enums!

[John Bafford]

> On Sep 17, 2015, at 20:06, Bob Weinand <bobw...@hotmail.com> wrote:
> 
>> Am 18.09.2015 um 01:52 schrieb John Bafford <jbaff...@zort.net>:
>> 
>> If we’re bikeshedding, one feature I would really like to see, with 
>> typehinting, is warnings if all cases of an enum aren’t handled in a switch. 
>> So, for example, given our example Weekdays enum, if I wrote this code:
>> 
>> switch(Weekday $someWeekday) {
>>  case Weekday::MONDAY: break;
>>  case Weekday::TUESDAY: break;
>> }
>> 
>> By providing the typehint, I’m indicating that I want to get a warning/error 
>> that the switch does not cover all enum values. This would be very handy if 
>> an enum value is added after initial development and someone misses a switch 
>> statement in cleanup.
>> 
>> The typehint would also allow generating a warning if someone did something 
>> like
>> 
>> switch(Weekday $someWeekday) {
>>  //case … all the weekdays: break;
>>  case ‘I am not a Weekday’: echo ‘Generate a fatal error here because 
>> string is not a Weekday.’;
>> }
> 
> So, you mean like an implicit
> default: throw Error("Unhandled enum value Weekday::FRIDAY");
> 
> Possible, but then you also just can add
> default: assert(0);
> instead of a typehint.
> 
> At compile-time won't be really possible, as, when the switch is encountered, 
> the enum might not yet have been loaded. That's one of the consequences of 
> PHP's lazy inclusion system...

Compile-time might not be possible, true, but at least this would provide for 
runtime checks, and the benefit of explicitly stating intention is that 
intention is explicitly stated. Also, it would allow the sort of errors I’m 
proposing be generated to all be standardized across all applications, which 
would allow fancy error handlers, such as with Symfony, to offer helpful 
context-specific suggestions. Also, it’d provide static analyzers additional 
information by which to provide correctness alerts.

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

Re: [PHP-DEV] Let's discuss enums!

[John Bafford]

On Sep 17, 2015, at 19:16, Bob Weinand  wrote:
> 
>> Am 18.09.2015 um 01:06 schrieb Rowan Collins :
>> 
>> This has come up in passing a few times recently, but I'm not sure there's 
>> ever been a dedicated discussion of it: would it be useful for PHP to have a 
>> built-in Enumeration type, and if so, how should it look?
> 
> I like enums in general, but I'd like to note that there's already a RFC in 
> draft by Levi:
> 
> https://wiki.php.net/rfc/enum 
> 
> As far as I know, the RFC is already fairly final and just lacks an 
> implementation.
> 
> So, I'd consider bikeshedding an actual RFC first.


If we’re bikeshedding, one feature I would really like to see, with 
typehinting, is warnings if all cases of an enum aren’t handled in a switch. 
So, for example, given our example Weekdays enum, if I wrote this code:

switch(Weekday $someWeekday) {
case Weekday::MONDAY: break;
case Weekday::TUESDAY: break;
}

By providing the typehint, I’m indicating that I want to get a warning/error 
that the switch does not cover all enum values. This would be very handy if an 
enum value is added after initial development and someone misses a switch 
statement in cleanup.

The typehint would also allow generating a warning if someone did something like

switch(Weekday $someWeekday) {
//case … all the weekdays: break;
case ‘I am not a Weekday’: echo ‘Generate a fatal error here because 
string is not a Weekday.’;
}

-John


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

Re: [PHP-DEV] Let's discuss enums!

[John Bafford]

> On Sep 17, 2015, at 20:15, Bob Weinand  wrote:
> 
>> Am 18.09.2015 um 01:56 schrieb Rowan Collins :
>> 
>> On 18/09/2015 00:16, Marcio Almada wrote:
>>> A kitten is working on thathttps://wiki.php.net/rfc/enum. Many points
>>> on the linked RFC are compatible to the points you raised so it might
>>> be worth reading before even starting any new proposal.
>> 
>> Aha, I hadn't seen that, should have thought to search the wiki. Still, 
>> interesting that we seems to mostly agree on the key decisions, although 
>> I've gone into more detail about things that he's left as Future Scope, 
>> which is fair enough.
>> 
>> The main thing I'd change if I was writing it is the implicit "ordinal" 
>> property; I don't really see the point of insisting that the order I write 
>> "Red, Green, Blue" has some meaning. On the other hand, I'd give much more 
>> prominence to the name, e.g. by making values() return an associative array. 
>> You're much more likely to want to say "the value whose name is 'RED'" than 
>> "the value I defined first in the list", IMHO.
>> 
>> If you have some kind of initialiser syntax for the values - with or without 
>> a constructor - you get to have ordinals or explicit values (like the Flags 
>> example) if you want them, and just names if not:
>> 
>> enum RenewalAction{
>>   Deny( 0 ),
>>   Approve( 1 );
>> 
>>   public $ordinal;
>> }
>> enum Flags{
>>   a (1  <<  0),
>>   b( 1  <<  1),
>>   c(  1  <<  2),
>>   d(  1  <<  3 ); public $value; }
>> 
>> enum PimaryColours { RED, GREEN, BLUE }
>> 
>> Regards,
>> 
>> -- 
>> Rowan Collins
>> [IMSoP]
> 
> The reason it is not an associative array is that the names are not important.
> 
> But we actually need ordinal(), else we'll end up writing 
> array_search(TheEnum::values(), $value).
> It's mainly important for the purpose of serializing/unserializing (manually 
> or internally).
> 
> You never should *rely* on the ordinal value of the enum for anything. Enums 
> are supposed to be value-less. It's a type. It's not a value. The only usage 
> of the value is going external.
> 
> Also, I honestly think the Flags example is a bad one. (At least as long as 
> we don't have a possibility to typehint combined enums...). If you need that, 
> use class constants. They provide exactly what you need.
> 
> Bob

Besides providing serialization mapping (or, the equivalent of a __toString() 
value if the enum is used in a strong context), an important benefit to 
providing a value for enums would be to allow for changing or deprecating 
enums. So you might want to say something like:

enum FormEvents {
PRE_SUBMIT,
PRE_BIND = PRE_SUBMIT, //deprecated name, provide mapping to new name
}

Another good reason for wanting to provide values is so that you could write 
code like this:

$eventHandlers = [
FormEvents::PRE_SUBMIT => function() { … },
FormEvents::POST_SUBMIT => function() { … },
...
];

Although maybe the ideal solution here would be to allow for array indexes to 
have more types than just int and string (so that the array index actually is 
the enum, not some serialized representation).

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

Re: [PHP-DEV] RFC: Nested enclosing returns

[John Bafford]

On Mar 21, 2015, at 10:17, Georges.L cont...@geolim4.com wrote:

 The main purpose of this RFC is *not* to improve the exception system of
 PHP but to improve the code logic/hierarchy.
 
 Hi php internals,
 
 After some long and deep research i finally decided to write my first RFC
 about a feature i'd be interested to be improved in the php core: *Nested
 enclosing returns*

Georges,

This would make simply looking at code and reasoning about what it does 
impossible.

At present, if I have the following code:

function foo() {
if(doSomething()) {
success();
} else {
failure();
}

return 42;
}

try {
bar(foo());
} catch($ex) {
}

Then I can make the following true statements about this code:
* foo always calls doSomething()
* foo always calls either success() or failure(), based on the result 
of doSomething()
* foo always returns 42
* bar is always called (with foo’s return value, 42)
* Alternatively to the above, any of the called functions may throw an 
exception, which will be caught by the catch block

If any of doSomething(), success(), failure(), or bar() can arbitrarily return 
to some higher calling scope, then the only thing I can say for sure is that 
doSomething() is called, after which my application could be in some 
dangerously inconsistent state because I have no idea what will be executed 
next.

This then provides significant security concerns. For example, if we have this:

function API_Function_With_Callback($callback) {
try {
$callback();

//do more stuff

return true;
} catch($ex) {
//do error stuff

return false;
}
}

function doEvil() {
$sentinel = //some unique value

$result = API_Function_With_Callback(function() use($sentinel) {
$backtrace = debug_backtrace();
$nestingLevel = //determine nesting level from backtrace
if($nestingLevel == 2) return $sentinel, 2;
else if($nestingLevel == 3) return $sentinel, 3;
else if($nestingLevel == 4) return $sentinel, 4;
// etc
}

// Exploit inconsistent state of Call_API_Function here
if($result === $sentinel) { … }
}

Then we can short-circuit code from some other library which isn’t prepared to 
deal with this kind of hijacking. More seriously, this sort of hijacking 
*can’t* be defended against (at least not without a weakening of your original 
proposal). Any function that takes a callback is potentially vulnerable to this 
sort of attack.


Can you suggest an actual, practical, example, where this would be such a 
benefit as to override the inherent difficulty about reasoning about this code, 
and the potential security concerns? Are there any other languages that make 
something like this possible?

I suspect that any code that could be “improved” with this functionality is 
already in significant need of improvement by more conventional means.

-John


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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[John Bafford]

On Mar 20, 2015, at 16:52, Stanislav Malyshev smalys...@gmail.com wrote:

 Hi!
 
 My proposal is something similar to Pythons slice, in PHP this would look
 like:
 
 $slided = $array[1:4]
 
 This will get the elements in positions 1,2,3,4. (1 through 4 inclusive),
 ignoring the actual key of the array. The result for an array will be an
 array with the keys preserved, in the same order.
 
 I'm not sure how such operation would be useful, and it definitely would
 not be intuitive, as $array[0] and $array[0:1] (assuming non-inclusive
 semantic, or [0:0] with inclusive semantics) would return completely
 different things. That would happen even if the array has only numeric
 keys! This is the main problem with this syntax - unlike most languages
 where it is used, PHP arrays are not vectors, they are ordered hashmaps.
 Sometimes this is very convenient, sometimes - like for this syntax - it
 is not. I think this is the major reason why such proposals failed in
 the past.

My interest in this proposal is mostly because it can potentially provide a 
convenient way to get the first element in an array, which is a not-infrequent 
need of mine.

I provided an array_key_first() implementation awhile ago that was first shot 
down because “too many array_* functions”, and then later ignored because I 
didn’t want to go through the RFC process just to add a few functions. (PR 
here: https://github.com/php/php-src/pull/347)

If people are generally interested in having an array_key_(first|last|index) 
implementation, I can dust off that PR, update it for master, and if we really 
need an RFC, I’ll prepare one for PHP 7.1.

-John


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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[John Bafford]

On Mar 20, 2015, at 16:27, Alex Bowers bowersb...@gmail.com wrote:

 On 20 March 2015 at 20:10, Sean Coates s...@seancoates.com wrote:
 
 That’s no different than `@` being invalid because it’s already in use.
 
 
 The syntax would be [*from:to], which would currently throw a parse error
 (since asterisk is required to be placed between two numbers), so this
 would be different.
 
 Alternatively, an underscore could be used
 
 This would then look like [_from:to]
 
 Also, another option would be to not use the square bracket syntax at all,
 and move towards angled brackets for positional indexing.
 
 This would then be $array1:2 to get items in positions 1 and 2.

$array1:2 could be confusing to parse (if not confusing to read) because of 
ambiguity with the existing  and  operators. For example:

$foo ? $bar1:2 3

is currently valid syntax, and means

$foo ? ($bar  1) : (2  3)

So there is probably some complex nesting of ?: and : that is entirely 
ambiguous.

Not necessarily saying it can’t be done, but I think we should probably avoid 
syntax with a significant chance of causing mental parse errors.

-John


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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[John Bafford]

On Mar 20, 2015, at 14:17, Rowan Collins rowan.coll...@gmail.com wrote:

 It doesn't work *with that syntax*, because -1 is a valid key, just as 
 $thing[0] can't mean first value of array because it already means value 
 with key 0. That's why I propose a new syntax such as $thing[@0], 
 $thing[@-1], etc.

I would just like to point out that the @ error suppression operator operates 
on expressions. Unfortunately, that means that also using @ as a slice operator 
makes the two ambiguous with each other in those contexts. The concept itself 
can still work, but it’d need a token other than @.

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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[John Bafford]

On Mar 20, 2015, at 16:10, Sean Coates s...@seancoates.com wrote:

 I posted four suggestions earlier,
 
 They were:
 
 @
 
 *
 ^
 
 My favourites are the asterisk or caret.
 
 That’s no different than `@` being invalid because it’s already in use.
 
 $ php -a
 Interactive shell
 
 php  define('a', 1);
 php  define('b', 2);
 php  echo @a . \n;
 1
 php  echo (ab) . \n;
 0
 php  echo (a*b) . \n;
 2
 php  echo (a^b) . \n;
 3
 php 
 
 However: `☃` has a long history of being available to PHP.
 
 S
 

There’s no existing unary form of  * and ^, though, so I think they’d both be 
available in this context (^ is my preference).

Overloading unary  would probably also work in this context, but personally, I 
think that  is too overused.

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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

[John Bafford]

On Mar 20, 2015, at 17:27, Stanislav Malyshev smalys...@gmail.com wrote:

 Hi!
 
 I provided an array_key_first() implementation awhile ago that was
 first shot down because “too many array_* functions”, and then later
 ignored because I didn’t want to go through the RFC process just to
 add a few functions. (PR here:
 https://github.com/php/php-src/pull/347)
 
 Adding array functions definitely requires and RFC process, arrays are
 primary data structure in PHP that stores practically everything, so
 having good API for them is essential. It's not that hard to make an
 RFC, and given that you propose a change which literally concerns
 millions of sites and developers, it's only to be expected that some
 formal description and discussion of the proposal is required.

Fair enough. Expect to see an RFC once the window for 7.1 opens.

 
 If people are generally interested in having an
 array_key_(first|last|index) implementation, I can dust off that PR,
 update it for master, and if we really need an RFC, I’ll prepare one
 for PHP 7.1.
 
 I imagine we do need an RFC for something like that. First element can
 be easily accessed with reset and each/current, but the last one is
 harder to access without modifying. So maybe it's be a good addition.
 There's a lot of time till 7.1 yet so you could definitely make a good RFC.

reset + each/current modifies the array pointer, though, so it’s unfortunately 
not quite that easy.

-John


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

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

[John Bafford]

On Oct 31, 2014, at 12:10, Andrea Faulds a...@ajf.me wrote:

 
 On 30 Oct 2014, at 21:57, John Bafford jbaff...@zort.net wrote:
 I would like to propose the creation of a team to triage the pull requests 
 on GitHub, to help ensure that the pull requests are handled in a timely 
 manner. I am also volunteering to lead such a team, should the RFC be 
 approved.
 
 https://wiki.php.net/rfc/github-pr
 
 PHP’s GitHub repository has over 180 open pull requests. Many of these are 
 bug fixes or new tests that should be incorporated into PHP, but have not 
 been because the PRs aren’t being regularly monitored. As a result, the 
 large number of open pull requests may also be discouraging contributions, 
 as potential contributors may see that pull requests are not being acted on 
 and decline to submit changes.
 
 Glad to see this, the pull request situation is really getting out of hand.
 
 I’d like to make a small request, though. For RFCs, there should be a 
 distinction between RFCs that haven’t yet passed, which have pull requests 
 mainly for code review purposes, and RFCs that have passed, which are waiting 
 to be merged. Actually, it might be best to generally ignore RFC pull 
 requests. For those that haven’t yet passed, they just want someone to look 
 at the code. For those that have, if the author has commit access, they don’t 
 need someone else to merge it, and the request is probably sticking around 
 because the patch isn’t yet fixed. The exception is pull requests for 
 accepted RFCs by authors who lack commit access: for these, someone will need 
 to go and merge them.

I think that GitHub PRs that reference an RFC need to be tagged as such, if for 
no other reason than to mark them as triaged, so that it’s clear that no label 
means only one thing (“hasn’t been triaged yet”). We’ll get into trouble if it 
ever becomes unclear why something is tagged/not tagged the way it is.

Having separate labels for the RFC’s status (rfc-draft, rfc-proposed, 
rfc-accepted, rfc-declined) would make it pretty easy to see what the state of 
things are, and shouldn’t be too much extra effort to keep updated; RFCs don’t 
change state all that frequently.

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

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

[John Bafford]

On Nov 1, 2014, at 10:27, Xinchen Hui larue...@php.net wrote:

 Hey:
 
 On Sat, Nov 1, 2014 at 7:53 PM, Pierre Joye pierre@gmail.com wrote:
 Hi,
 
 On Oct 31, 2014 4:57 AM, John Bafford jbaff...@zort.net wrote:
 
 Hi,
 
 I would like to propose the creation of a team to triage the pull
 requests on GitHub, to help ensure that the pull requests are handled in a
 timely manner. I am also volunteering to lead such a team, should the RFC
 be approved.
 
 https://wiki.php.net/rfc/github-pr
 
 PHP’s GitHub repository has over 180 open pull requests. Many of these
 are bug fixes or new tests that should be incorporated into PHP, but have
 not been because the PRs aren’t being regularly monitored. As a result, the
 large number of open pull requests may also be discouraging contributions,
 as potential contributors may see that pull requests are not being acted on
 and decline to submit changes.
 
 As much as I like the idea I never understood why we do not have them here.
 
 Given that many PRs have discussions, it should show up on internals.
 
 PS: yes we have a PR list. Which did not work as expected. PRs and
 discussions in them should not be considered as noises to the internals list
 Cheers,
 Maybe we should create some tags , like minor, critical, need verify 
 etc..
 
 for minors, anyone have time can merge it. (like typo fix).
 
 thanks

At the moment, I would be wary of trying to do too much at the start. Having a 
process and team in place for getting the PRs triaged is more important than 
also rating PRs for severity. Once we get this going and see how it’s helping 
the overall workflow, we can better consider the best ways to expand from there.

Adding severity labels is certainly something that we can do in the future. I 
do note, though, that bugs.php.net does not appear to have a severity rating; 
tickets are only tracked according to bug/feature/docs/security, and the RFC 
currently has labels for the first three of those. I think if we’re going to 
start adding additional labels that go beyond triage, we’d want to coordinate 
that with bugs.php.net, and that’s getting to be outside of the scope of this 
RFC.

Also: would we even want to add a label for security? If I’m remembering 
correctly, PHP has a separate (and initially closed) process for tracking 
security issues, so we may not want to advertise that a PR is security related 
until after there’s an official announcement. (I think this also means that PRs 
through GitHub are not likely to be security related. But I’m open to 
comments/suggestions on the matter.)

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

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

[John Bafford]

On Nov 1, 2014, at 08:28, Rowan Collins rowan.coll...@gmail.com wrote:

 On 1 November 2014 11:53:11 GMT, Pierre Joye pierre@gmail.com wrote:
 Hi,
 
 On Oct 31, 2014 4:57 AM, John Bafford jbaff...@zort.net wrote:
 
 Hi,
 
 I would like to propose the creation of a team to triage the pull
 requests on GitHub, to help ensure that the pull requests are handled
 in a
 timely manner. I am also volunteering to lead such a team, should the
 RFC
 be approved.
 
 https://wiki.php.net/rfc/github-pr
 
 PHP’s GitHub repository has over 180 open pull requests. Many of
 these
 are bug fixes or new tests that should be incorporated into PHP, but
 have
 not been because the PRs aren’t being regularly monitored. As a result,
 the
 large number of open pull requests may also be discouraging
 contributions,
 as potential contributors may see that pull requests are not being
 acted on
 and decline to submit changes.
 
 As much as I like the idea I never understood why we do not have them
 here.
 
 Given that many PRs have discussions, it should show up on internals.
 
 PS: yes we have a PR list. Which did not work as expected. PRs and
 discussions in them should not be considered as noises to the internals
 list
 
 It depends on the type of discussion - PR discussions can be an opportunity 
 for code review and discussing the minutiae of the implementation, which 
 don't really warrant forwarding to a wider audience. If the discussion 
 becomes about the merit or impact of the change itself, then a discussion on 
 Internals might make sense. The same is true of bug discussions; having every 
 comment on every bug flood the list wouldn't make sense, but some should 
 probably be forwarded here to get a wider audience.
 
 I don't know what the volume in this case would be, though. If there were 
 several posts popping up on Internals every day about someone misplacing a 
 curly brace, I would definitely think it was noise; if it were a few threads 
 a week, mostly discussing the actual substance of changes, I'd be fine with 
 it.

I would expect that, at the least, there would be an uptick in discussion just 
as a result of weekly PR summary making the pending PRs more visible. My guess 
is that there might be a lot of discussion and/or noise initially as we get the 
current backlog (185 PRs currently open) whittled down to something more 
manageable, so it might take a few months after the RFC is adopted for the true 
nature of the volume increase (if any) to become apparent.

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

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

[John Bafford]

On Oct 31, 2014, at 12:15, Ferenc Kovacs tyr...@gmail.com wrote:

 On Fri, Oct 31, 2014 at 3:13 PM, Florian Anderiasch m...@anderiasch.de
 wrote:
 
 On 31.10.2014 09:58, Peter Cowburn wrote: On 30 October 2014 21:57,
 John Bafford jbaff...@zort.net wrote:
 
 Hi,
 
 I would like to propose the creation of a team to triage the pull
 requests
 on GitHub, to help ensure that the pull requests are handled in a timely
 manner. I am also volunteering to lead such a team, should the RFC be
 approved.
 
 
 Slightly off-topic, but how about the same thing for bugs.php.net and
 patches?
 
 This implies that on bugs and with PRs it's the same issue.
 My cautious guess is that permissions to merge PRs on GitHub (which not
 all developers can do) are not the main reason that stuff doesn't get
 merged.
 
 
 when qa.php.net is not dead, anybody with a php.net account is allowed to
 comment/close github PRs.
 for merging them, you are still required to have the appropriate karma to
 be able to push it to git.php.net.
 
 
 Whereas on the bug tracker, afaik everyone with a php.net account can
 triage, edit, assign, etc bugs. And still there are open ones.
 
 
 I think that from the who can do what perspective those two are similar,
 anybody can help to review/debug and propose a improvements/solution or
 close the bogus reports/PRs, but at the end of the day, only those with
 approrpiate karma can merge the PR/patch for the fix.


I think what’s on bugs.php.net and what’s in a GitHub PR are largely two very 
different things, requiring two separate skill sets.

bugs.php.net is a bug and feature request database, and is a primary interface 
for *users* of PHP to ask for things. While you can provide a patch or a GitHub 
PR with an entry, the triage process for the bug database is likely to revolve 
around attempting to reproduce or confirm problems, de-duping, and then 
eventually getting someone to actually fix the bug or implement the feature.

A PR in GitHub, on the other hand, comes with (presumably working) code, so it 
jumps to the end of the line: validation that the code is correct and (in the 
case of new features, which should have an accompanying RFC) is the sort of 
thing we want in PHP.

I agree that there needs to be a triage team for bugs (there are 5,219 open 
bugs in the db since 1999, a large number of which I’m guessing are actually 
dups, invalid, already fixed, or wontfix), and while it’s also an important 
job, it’s also outside the scope of the problem I’m trying to solve (actual 
written code that could go in, but is languishing instead). I’d like to get the 
GitHub triaging set up first since in theory all the PRs are actionable, and if 
we want to set up a formal triage team/process for bugs, we can discuss how 
best to manage that without biting off too much at one time. (PR triaging can 
realistically be done by one person; but going through the bugs backlog really 
is going to require a several person team, and probably one that collectively 
has experience with the entire PHP feature set.)



 So, if it's only a permissions issue and people are active hindered to
 get stuff done, go ahead and propose changes. If it just feels like
 stuff doesn't get done... maybe no one's around to do it.
 
 
 personally I think that we lack people for both triaging/reviewing and
 merging/pushing the changes.
 So anybody willing to look into bugs/PRs are more than welcome, and even if
 he/she don't have the knowledge or karma to fix/merge the issue, it will
 already make it easier for those who do to do the last step.

Yes, this exactly. And I’m envisioning that at some point, the GitHub PR Triage 
Team would also have the karma to commit the simple, non-controversial items, 
which would allow the more senior devs to focus on the 
larger/controversial/more important items.


 ps: if you need help for getting something looked at, org merged, feel free
 to ping the RMs and/or complain on internals@, because it is easy for us to
 miss things because of the already huge backlog of open bugs/PRs. I
 personally think that we should make some drastic measures to bring down
 the open bugs/feature requests to a managable level (see
 http://www.joelonsoftware.com/items/2012/07/09.html) as currently we have
 all the bugs/features reported since 1999.

We can avoid declaring bankruptcy on the PRs since there’s relatively few of 
them, and getting a triage team off the ground will help us from ever having to 
do that. I don’t know that we should declare bug bankruptcy, but if we do, we 
should first figure out how we’re going to go forward to make sure we never 
have such a huge backlog again.

But I also think that dealing with the bugs situation is a separate discussion. 
Let’s get GitHub PR triage going first, and we can apply any lessons we learn 
to the other problems.

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

[PHP-DEV] [RFC] GitHub Pull Requests Triage Team

[John Bafford]

Hi,

I would like to propose the creation of a team to triage the pull requests on 
GitHub, to help ensure that the pull requests are handled in a timely manner. I 
am also volunteering to lead such a team, should the RFC be approved.

https://wiki.php.net/rfc/github-pr

PHP’s GitHub repository has over 180 open pull requests. Many of these are bug 
fixes or new tests that should be incorporated into PHP, but have not been 
because the PRs aren’t being regularly monitored. As a result, the large number 
of open pull requests may also be discouraging contributions, as potential 
contributors may see that pull requests are not being acted on and decline to 
submit changes.

Thanks,

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

[PHP-DEV] VCS Account Request: jbafford

[John Bafford]

I would like access to edit the wiki and submit RFCs.

Thanks,

-John

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

Re: [PHP-DEV] PHP class files without ?php at the top

[John Bafford]

On Apr 7, 2012, at 09:39, Tom Boutell wrote:

 From the viewpoint of someone writing reusable classes, the need to
 start with ?php and reprimand anybody who accidentally puts a newline
 above it is a silly annoyance they don't experience with other tools.
 
 That said, you are making valid points, I'm not convinced myself that
 file extensions necessarily should or could be determined in every
 context. But it seems the most viable way of addressing the issue - if
 a viable way even exists. Partly I want to convince myself that this
 either can or can't ever be improved, and move on either way (:

That silly annoyance doesn't seem to bother anyone who writes command line 
tools, which require the #! line specifying the command interpreter to be the 
first bytes in the file, with no leading white space whatsoever. Especially on 
unix systems (but also on the Mac), the file extension does not affirmatively 
indicate the file type or whether or not it can be executed.

Also, from a CLI perspective, you don't want extensions in the names of your 
scripts, because then it causes problems/confusion/extra work if you later 
decide to change the language the script is written in.

-John

--
John Bafford
http://bafford.com/


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

Re: [PHP-DEV] PHP class files without ?php at the top

[John Bafford]

On Apr 7, 2012, at 10:00, Tom Boutell wrote:

 That's a good point too.
 
 I think this is a better proposal:
 
 include_code, require_code, and require_code_once would work just like
 include, require and require_once, except that the parser would start
 out in PHP mode.

Those might be nice functions to have, but ...

 .phpc is then just a convention for naming PHP files that start out
 with code - a convention that autoloaders should respect, just as they
 now respect the .php convention. The user asked for the Monkey class,
 and I see Monkey.phpc is out there; I'll grab that with
 require_code_once.

… I think this isn't quite as simple as you make it out to be. Any autoloader 
that cared about bc would have to have code like

if(file_exists(.phpc)) require_code() else if(file_exists(.php)) require() else 
HCF()

There's a reason everyone settled around a single extension, and not the 
plethora we used to have (php, phtml, php3/php4, others?). Even in the 
rainbows-and-unicorns world where everyone always has an opcode cache and 
suitably tuned stat cache, that extra call to file_exists that will likely 
happen while waiting for files to be renamed and tested still isn't free. Also, 
I'm willing to bet that in the unlikely event you chose to drop out of PHP mode 
to dump a block of HTML, the awkwardness of a sudden ? without a leading ?php 
would make the discussions about whether or not to have a trailing ? at the 
end of files look like hyper-civilized discourse in comparison. (Though, it 
might be an interesting discussion regarding making the hypothetical 
require_code only (directly) include files that are pure code, with no ?php ? 
tags allowed.)

Personally, I think the cognitive overhead the ?php ? tags impose is pretty 
tiny. Yeah, you get weird errors sometimes, but once you understand what's 
going on, it's easy to fix (and generally easy to spot, if you're using version 
control). I really can't recall the last time it's happened to me and it took 
more than ten seconds to identify and fix. It's just one of the weird things 
about php. Every language has its rough edges, and in comparison, I really 
don't think this one even ranks in the top ten. There are plenty other parts of 
PHP that are far more awkward that could use addressing first (but won't, 
because of the bc break involved; haystack, meet needle).

You could also view ?php at the top of the file as a sort of magic number 
indicating the file type (such as used in many binary file formats: gifs always 
start with GIF87a/GIF89a, java class files with 0xCAFEBABE, etc). It's unlikely 
a file that starts with ?php is anything but.

-John

 Putting this decision on the autoloader makes more sense because
 autoloaders already contain assumptions about file extensions. They
 have to in order to do their job of translating a class name to a
 particular path somewhere.
 
 Folks who did not care for this functionality could then choose to
 entirely ignore it. Class library developers who liked it would make
 autoloaders available that honored it, freeing end-user developers
 from thinking about it. It becomes self-contained, and people who are
 writing old-school .php standalone scripts or pages are entirely
 unaffected.
 
 On Sat, Apr 7, 2012 at 9:50 AM, John Bafford dsha...@zort.net wrote:
 
 On Apr 7, 2012, at 09:39, Tom Boutell wrote:
 
 From the viewpoint of someone writing reusable classes, the need to
 start with ?php and reprimand anybody who accidentally puts a newline
 above it is a silly annoyance they don't experience with other tools.
 
 That said, you are making valid points, I'm not convinced myself that
 file extensions necessarily should or could be determined in every
 context. But it seems the most viable way of addressing the issue - if
 a viable way even exists. Partly I want to convince myself that this
 either can or can't ever be improved, and move on either way (:
 
 That silly annoyance doesn't seem to bother anyone who writes command line 
 tools, which require the #! line specifying the command interpreter to be 
 the first bytes in the file, with no leading white space whatsoever. 
 Especially on unix systems (but also on the Mac), the file extension does 
 not affirmatively indicate the file type or whether or not it can be 
 executed.
 
 Also, from a CLI perspective, you don't want extensions in the names of your 
 scripts, because then it causes problems/confusion/extra work if you later 
 decide to change the language the script is written in.
 
 -John
 
 --
 John Bafford
 http://bafford.com/
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 
 -- 
 Tom Boutell
 P'unk Avenue
 215 755 1330
 punkave.com
 window.punkave.com
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

--
John Bafford
http://bafford.com/


--
PHP Internals - PHP Runtime Development Mailing List

Re: [PHP-DEV] PHP class files without ?php at the top

[John Bafford]

On Apr 7, 2012, at 10:53, John Crenshaw wrote:

 I don't like this, but it's closer. I hate the idea of adding a whole mess of 
 one-off functions just to support a single coding style feature that doesn't 
 seem to have very much support. There are a variety of other ideas that have 
 been floating around that request changes to how the parser handles specific 
 code (different short tags, sandboxing, auto-escaping, etc.).
 
 What if you have just ONE function with a variety of options? Something like:
 
 execute_file('path/to/foo.php', array(
'require'=true,
'once'=true,
'begin_code'='?php ',
'shorttags'=array('?=','?'),
'autoescape'=function($str){return htmlentities($str, ENT_QUOTES | 
 ENT_HTML5, 'UTF-8');},
...
 ));

While there's some elegance with your execute_file (there'd definitely be 
benefits to one function instead of the four we have now), the extra options 
would spawn so much Daily WTF material it wouldn't be funny, and I think most 
people would just stick with include/require/*_once because there'd be a lot 
less effort in the common case.

 This would provide a single consistent hook for any further DSL like features 
 without impacting the behavior of any existing code. Some other options that 
 might make sense:
 
 lint (like command line)

Actually, it'd be pretty cool to be able to lint a file without having to 
include runkit (there is a runkit_lint($code)) or make an external call to php 
-l.
 
 end_code (similar to command line, corresponds with begin_code (also command 
 line)) 
 args (also command line)
 Any PHP_INI_ALL directives
 
 John Crenshaw
 Priacta, Inc.


-John

--
John Bafford
http://bafford.com/


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

[PHP-DEV] Add E_STRICT when defining a required function parameter after an optional parameter

[John Bafford]

Hi,

I filed a bug report with an attached patch that adds an E_STRICT warning when 
defining a function with a required parameter after an optional function 
parameter, for example:

function foo($optional = 1, $required) {}

Although doing this works, code written like that is probably making a faulty 
assumption somewhere, and emitting this error would help raise the quality of 
php code.

The bug and patch are here: http://bugs.php.net/bug.php?id=53399

The patch applies against both the PHP 5.3 branch, and trunk. I'm not sure I'd 
advocate including it in PHP 5.3, but I'd definitely like to see it in 5.4. The 
patch also includes two tests, and fixes this problem in the 
Zend/tests/call_user_func_005.phpt test, which is the only test I found that 
fails as a result.

At some point in the future, I would like to make this a more severe error than 
an E_STRICT, but I'd rather not immediately break code that (until now) worked 
without warning.

Thoughts/comments?

-John

--
John Bafford
http://bafford.com/


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

Re: [PHP-DEV] Add E_STRICT when defining a required function parameter after an optional parameter

[John Bafford]

On Nov 24, 2010, at 14:02, Stas Malyshev wrote:
 Given the semantics of PHP arguments, there is nothing wrong with
 defining a required argument after an optional one, and in some cases
 it is required. Consider:
 
 I think there's something wrong with it, primarily - the fact that it doesn't 
 really make any sense. The object/null thing is a kludge. Unfortunately, I 
 don't see a proper way to handle this without named arguments.


Ok, I re-wrote the patch and test:
http://bugs.php.net/patch-display.php?bug_id=53399patch=strict-required-opt2.patchrevision=latest

Now, the test happens in zend_do_end_function_declaration(). It loops through 
each of the function's parameters and emits the E_STRICT if it detects a 
required parameter after an optional parameter. The tests are loosened so that 
Class $param = null will not by itself trigger the warning. So it's not a 100% 
solution since we have to allow for the object/null kludge, but it's still an 
improvement from not having anything at all.

To make this work, I added a field to zend_arg_info, 'optional', which is 
populated in zend_do_receive_arg(). Also, we might want to modify 
php_reflection.c:_parameter_string() to use zend_arg_info.optional, which would 
allow indicating whether the parameter was declared optional vs. whether it 
actually is being treated as optional.

I think I can move the implementation back into zend_do_receive_arg(), but 
before I go ahead and do that, I'd like to make sure everyone's happier with 
this solution than my first. It might also be possible to get rid of 
zend_arg_info.optional, but I'd need to know how/if it's possible to access the 
relevant oplines for the rest of the function's parameters.

-John

--
John Bafford
http://bafford.com/


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

[PHP-DEV] [PATCH] New functions: array_key_index(), array_first(), array_last()

[John Bafford]

() with negative offset:
string(3) one
string(5) first

Testing array_index() with positive offset past the end of the array:
NULL
string(5) first

Testing array_index() with negative offset past the end of the array:
NULL
string(5) first


--
John Bafford
[EMAIL PROTECTED]
http://www.dshadow.com/



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