I still need add in control structures and magic methods (that are not included, switch, return, __construct() et al), and scrape up all the functions that are not listed under function.* but in the likes of mysqli::query, mysqli_query as “object-oriented style” and “procedural style”, so-called. Which brings me to my question. I’m reading the auto-completion docs and there’s this:

The basic character set used to recognize keywords is made of letters a-z, A-Z, digits 0-9, and the underscore _. Punctuation might work for auto-completion; however, if you want to use the parameter hints, you should not use punctuation in the keyword name.

An example from the PHP manual on mysqli_query:

// Object-oriented style
public mysqli::query( string $query, int $result_mode = MYSQLI_STORE_RESULT) : mysqli_result|bool

// Procedural style
mysqli_query( mysqli $mysql, string $query, int $result_mode = MYSQLI_STORE_RESULT) : mysqli_result|bool

Obviously :: are punctuation. This would mean that e.g. mysqli::query as a keyword would disable parameter hints. Tested and indeed so it does. Also to note, the “procedural” variant typically has a different signature (with an object passed as the first argument).

Then, what’s the preferred way of handling these situations? Ignore the :: variant? Or include it and let the hints not be shown? In any case, the :: versions are rarely (I think?) used for static calls with the literal class name, and it’s really only the class name (and constructor signature?) that’s conceivably helpful to include in autocomplete.

Also, there are any number of built-in classes with their methods that don’t have an “alternative access” variant. Example:

public PDOStatement::bindParam( string|int $param, mixed &$var, int $type = PDO::PARAM_STR, int $maxLength = 0, mixed $driverOptions = null) : bool

I’d be inclined to add PDOStatement as a separate keyword. This leaves the question of what to do with bindParam(). In this case there’s no collision, so it could go in, an orphan with its parameter hints. However e.g. PDO::prepare and mysqli::prepare have different signatures, and doubtless there are plenty more like that. And damned if I’ll be manually curating collisions for this. Also, adding in each method from each built-in class would conceivably create a lot of suggestion noise.

In any case, it seems that all the built-in class names (SPL) deserve to be included in the definitions on their own. Anybody feel like typing new RecursiveCallbackFilterIterator() a couple of times over huh?

Then, any feedback welcome on best practices here. While I’m at it and the scripts are still warm, I might as well scrape up current CSS and JS/ES6 definitions and update them. Seem a bit dated as well. To be continued. Thanks for all the great work with NP++.