View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 3978 | Composr testing platform / automation goals | General / Uncategorised | public | 2019-12-06 03:07 | 2019-12-06 13:54 |
| Reporter | Chris Graham | Assigned To | Guest | ||
| Priority | normal | Severity | feature | ||
| Status | new | Resolution | open | ||
| Summary | 3978: Further PHP validation - to generalise the CQC and make it a standalone project | ||||
| Description | The CQC readme.txt file contains notes of things we don't support. The 4 I feel somewhat bad about are: 1) We don't have any Iterator support. We don't use it in Composr and I'm against how PHP does it on principle, but it seems someone might use it and be upset that the CQC won't validate looping over an object implementing Iterator. 2) We don't do any namespace resolution. As Composr is not a library/framework, we don't need to put stuff in namespaces, and don't need to validate them. This would upset some people, who like to make massive Java-like class hierarchies. Our CQC would not be able to handle this unless all class names were always referred to in fully-qualified form, or if they were simply declared (in the CQC's special way) as extra classes to be dumbly whitelisted. 3) We don't do any object property validation (check existence, check types, check scope). Now generally speaking properties will rarely be directly accessed from outside of an object, as that is bad style - and inside an object it would be unlikely for a programmer to be screwing up access of properties in the same region of code (generally when doing big refactoring things break between files, not within). But I still feel it would be great to add this. The problem is that the PHP function/class signature compilation code would need to be a lot smarter. The way it works now is it just scans for class/function/etc headers and builds up the signature database - but to do property validation it would need to do smarter parsing of declared properties. 4) Similar, but for class constants (scope is only available in PHP 7.4 IIRC though). These are all somewhat big jobs with diminishing returns, but they are significantly hampering what the CQC can do as a more general purpose tool that would make the wider PHP community happy. I would love some day to have the CQC let loose as a fully standalone project. This week I've compared other PHP linting tools and the CQC may actually be better than all of them for general purpose non-burdensome PHP linting, assuming we generalised the codebase. The only other linter that really competes is PHPStorm's built in inspections, and that's a commercial project. It would be a lot of work to set CQC loose though. There's a lot of stuff in there that hard-codes Composr that would need to be made more configurable. I doubt I'd personally have the funding to do it, maybe someone would though. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Time estimation (hours) | 250 | ||||
| Sponsorship open | |||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-12-06 03:07 | Chris Graham | New Issue | |
| 2019-12-06 13:54 | Chris Graham | Relationship added | related to 2747 |
| 2023-02-26 18:29 | Chris Graham | Category | General => General / Uncategorised |
