Skip to content
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

Version 4 BC idea list #6155

Closed
SpacePossum opened this issue Dec 8, 2021 · 4 comments
Closed

Version 4 BC idea list #6155

SpacePossum opened this issue Dec 8, 2021 · 4 comments

Comments

@SpacePossum
Copy link
Contributor

SpacePossum commented Dec 8, 2021

Hi all,

Basically I would like to share a list of v4 BC ideas I got. Mainly to get feedback and see what others think.


I would like to have custom tokens for all different types of usages of the following symbols.

: :

  • goto
  • alternative syntax control structure
  • before return type hint in function signature (T_TYPE_COLON, listed here for completeness)
  • named argument (CT::T_NAMED_ARGUMENT_COLON, listed here for completeness)
  • in use of switch-case

&:

  • pass by reference in signature and reference variable name ($b = &$a;)
  • bitwise operator
  • type intersect (CT::T_TYPE_INTERSECTION, listed here for completeness)
  • return reference (CT::T_RETURN_REF, listed here for completeness)

| :

  • bitwise operator
  • type alternation ([CT::T_TYPE_ALTERNATION, listed here for completeness)

I would like the exit code to changed when a file got fixed or needs fixing. If the fix is done successful the tool currently ends with exit code 0 unless running with the dry-run flag, I would like this exception to go away and not exit with code 0.


In general to have a look at single use classes to see if it makes sense to not merge these (for example NamespacedStringTokenGenerator ) with the caller/use class.


Deprecate FinalClassFixer in favor of FinalInternalClassFixer - #6128
Drop alternative syntax by default for all build in fixers - #6003


start looking for external library managing types parsing for PHPDocs

#6063 (comment)


CT type of the enum case vs. swtich case

@kubawerlos
Copy link
Contributor

This ☝🏼 and the priorities.

I'm thinking about creating in v3 new interface like:

interface NewFixerInterface extends FixerInfertace
{
    public function getFixersToRunAfter(): array {}
}

and deprecate FixerInfertace::getPriority - in 4.0 NewFixerInterface will be removed and getFixersToRunAfter will go to FixerInfertace to replace getPriority.

The runner then will get the list of fixers somehow sorted (like we have the fixer that always run first) and after running every fixer will have a list of fixers still to run and will update that list with getFixersToRunAfter results.

This will solve problem of circular priorities which now cannot be addressed. But, it will bring new problems - performance (how much will that slow down the fixer? Some fixers might need to run multiple times) and how to handle situation when set of fixers reverts each others and are still on a list of fixers to be run?


Or, maybe we do not want to have getFixersToRunAfter, but getFixersToRunBefore (similarly it will replace getPriority in v4) - and we build the set to run with the information which fixer "blocks" which (when fixer is unblocking other fixers) - this way we keep the same performance, but will still have circular dependencies problem. This solution basically replace numbers from getPriority with list of fixers.

@keradus
Copy link
Member

keradus commented Dec 8, 2021

proposal - let's create a label/milestone marker for BC breaks and have a way to discuss each idea separately. otherwise it will be a mess with constant changing of WHICH bc break we discuss

@kubawerlos
Copy link
Contributor

@SpacePossum for the transformers what about BC break for the interface? NameQualifiedTransformer is a killer for large files, such as https://raw.githubusercontent.com/sabbelasichon/typo3-rector/v0.11.32/config/composer/typo3-87-composer-packages-extensions.php

It's not a problem if 4.0 will be fot PHP 8+ only.

@WinterSilence
Copy link

WinterSilence commented May 9, 2022

  1. Mark fixes supports alternative syntax like as "risky rule" i.e. alt. syntax rule must instance interface AltSyntaxFixerInterface extends FixerInterface {public function altFix(\SplFileInfo $file, Tokens $tokens): void;} because in most case alternative syntax using only in "views" files and views don't mix syntaxes.

  2. Need high-level API/tools for working with code as with abstraction.
    2.1. Create high-level API to parse PHP code as nested tree or use something like AST parser.
    2.2. Get parent/context Reflection for AST leaves (namespace, class/interface/trait or function/method)
    2.3. Get Reflection for AST leaves of native PHP stuff by stubs (if function/class not exists in using version of PHP)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants