-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discuss: (PHP) built-ins are currently purposely not highlighted. #2996
Comments
There ( PHP does not currently highlight built-ins such as If there is a full list of built-ins available I'd be curious to see it, but I worry it might be too large (since PHP is also included in our |
We need to get the details here on how long a full list would be and see if anyone is willing to work on generic function dispatch detection for PHP. If neither of these seems to be viable then this will be auto-closed at some point as "expected behavior" - with #2500 tracking the overall issue (of improved fidelity across all grammars for function dispatch). |
Here is a list: https://www.php.net/manual/en/indexes.functions.php I don't think highlighting built-in functions at the cost of storing this many functions is worth it. I think even the built-in interfaces list is a far fetch to be honest. |
Yikes. Fully agree.
You mean the But a list of pure interfaces is no help at all if interfaces aren't commonly named in actual PHP code... Does PHP have the common convention that CamelCasedThings are always interfaces/classes? |
All those interfaces are somewhat niche interfaces, but I think
Internally, functions are declared with snake_case, and interfaces/classes with CamelCase. However, they are all case-insensitive. It's unlikely to not use that pattern, but it's not technically wrong code if someone were to use SnakeCase functions or SCREAMCASE class names for example. |
Unfortunately, PHP classes and functions are case-insensitive. |
OH grrrr... and therefore we have to flag the language as
If they are rarely used (niche) then they might be a strong signal but quite expensive (in terms of us maintaining a big list) and in an overall sense not useful... if 95% of PHP code wouldn't ever reference them - we should drop them. The kind of lists we want are lists where 95% of PHP code/snippet MIGHT use those words (which is why keywords are always a good bet)... The problem with "selective" lists comes when someone says why do you highlight the popular built-in SnapperInterface but not the built-in BoogerInterface... which leads back to perhaps trying to find a way to highlight ALL interfaces... (by case convention) and have a smaller list only for auto-detection purposes. This is also a discussion happening with regards to Javascript. |
I understand that removing the list of built-in interfaces is a breaking change in a semver sense. With PHP getting more and more object-oriented, I don't think its feasible to keep an up-to-date list of interfaces or internal classes. In fact, there was a proposal just today to introduce a new interface. Language constructs like Case sensitivity in PHP is all over the place too. Variables are case-sensitive, but function names, classes, enums, attributes, etc are case-insensitive. We are generally moving into case-sensitive approach though, but it's highly unlikely that existing structs will change. Constants for example, lost their ability to declare a case-insensitive constant, and recently added named parameters are also case-sensitive. Personally, I'd all in favor to:
|
Thanks so much for feedback.
What about keywords? That's the real issue, we don't have a way to do case insensitive keywords apart from making the grammar case insensitive. We could maybe hack it, but I'm not thrilled with the idea.
Makes sense to me, but we still need to highlight them - or else PHP will look very "dry". Would doing so via CamelCase work? If so we still have to tackle the case sensitivity issue to even be able to detect camelcase...
We do not consider highlighting changes within grammars to be "breaking" changes in a semver sense - the grammars are always improving and in flux. We do try to avoid going the wrong direction with a grammar though - ie they don't get "worse" often.
That's usually a reason they should stay. One could argue to just include the most popular, but we aren't that tight on space... so if there are only a handful it's easy to just list them all... unless there are really 200 and we only have a few now, in which case revisiting trimming a few more could be done... Just replacing with a |
Keywords are case-insensitive as well. There are some changes in PHP 8.0 to allow reserved keywords be part of namespaces for example, but they will keep its semantics.
I think you are right, special with language-detection. PHP language detection is a bit difficult as-is, with its following c-like syntax/comments and
I think we have great title highlighting already. I tested with |
I'm talking built highlighting them as keywords without context.
Currently we highlight ArrayAccess there, not as a |
Some tests that need to be performed: class HighlightMe {}
interface HighlightMe {}
class HighlightMe extends HighlightMe {}
class HighlightMe implements HighlightMe {} $a = new HighlightMe;
$b = new HighlightMe(); public HighlightMe $a;
public array $b = []; if ($a instanceof HighlightMe) {} $a = HighlightMe::const;
$b = HighlightMe::method(); use HighlightMe;
use HighlightMe as HighlightMe; function foo(HighlightMe $a, array $b, $c = null) {}
function foo(): HighlightMe {} |
@Ayesh I'd say if you want to do this along with the other work you're doing on PHP lately this would be a small improvement. We may want to move the few remaining to a |
Closing this original issue as #wontfix, expected behavior in agreement with @Ayesh:
We only highlight reserved words - not ALL built-ins (which is a huge list), though there is already separate discussion to highlight all function dispatch as part of the #2500 initiative. |
Describe the issue
Which language seems to have the issue?
Are you using
highlight
orhighlightAuto
?Sample Code to Reproduce
Expected behavior
Additional context
The text was updated successfully, but these errors were encountered: