Move operator definitions to objects #4543
Conversation
fabpot
force-pushed
the
operator-classes
branch
5 times, most recently
from
4461487 to
bd7a8df
Compare
fabpot
force-pushed
the
operator-classes
branch
from
bd7a8df to
4e4d23b
Compare
fabpot
force-pushed
the
operator-classes
branch
from
4e4d23b to
1fdaa88
Compare
fabpot
force-pushed
the
operator-classes
branch
5 times, most recently
from
1749107 to
3d0e2f3
Compare
|
New iteration where I have moved most pseudo-operators (logic hardcoded in |
fabpot
force-pushed
the
operator-classes
branch
5 times, most recently
from
339a8c3 to
4bf41b7
Compare
| @@ -0,0 +1,56 @@ | |||
| Unary operators precedence: | |||
There was a problem hiding this comment.
This doc is the most important part of this PR.
We need to review the precedence order carefully.
fabpot
force-pushed
the
operator-classes
branch
2 times, most recently
from
35ef5c7 to
0704840
Compare
|
|
||
| public function getOperator(): string | ||
| { | ||
| return '('; |
There was a problem hiding this comment.
I find it really weird to treat parenthesis as a unary operator (its parsing implementation does not look like the parsing of an expression either btw)
| 300 | | ||
| . | ||
| [ | ||
| ( |
There was a problem hiding this comment.
I think this needs more explanation to indicate that this parenthesis is representing the function call. I know no language that describe function calls as being a binary operator
There was a problem hiding this comment.
this precedence looks weird to me compared to unary operators. How is - myfunc() parsed, before and after this change ? Same for - var[0]
There was a problem hiding this comment.
Btw, what happens if an extension defines an operator with higher precedence that this "function call" operator ? Using a function call near this operator would suddenly not parse the function call in the expected way.
| public function __construct(array $items, int $lineno) | ||
| { | ||
| foreach ($items as $item) { | ||
| if (!$item instanceof ContextVariable) { |
There was a problem hiding this comment.
Do we need to validate this here ? Isn't this also ensured by the parser when using parsing ?
For custom constructed nodes, we already have the parameter type defining the contract and we generally don't add runtime checks for array values when we have such contract.
| $this->pushToken(Token::OPERATOR_TYPE, preg_replace('/\s+/', ' ', $match[0])); | ||
| $operator = preg_replace('/\s+/', ' ', $match[0]); | ||
| $type = Token::OPERATOR_TYPE; | ||
| // to be removed in 4.0 |
There was a problem hiding this comment.
This removal will likely make things weird for the token stream (which will impact custom token parsers). After this removal, ( would generator an OPERATOR_TYPE token, while ) will not (will it stay a PUNCTUATION_TYPE ? it depends how the new PUNCTUATION constant will look like)
fabpot
force-pushed
the
operator-classes
branch
2 times, most recently
from
dc96f57 to
ec728b6
Compare
CHANGELOG
Outdated
| @@ -1,6 +1,9 @@ | |||
| # 3.20.0 (2025-XX-XX) | |||
|
|
|||
| * n/a | |||
| * Bump minimum PHP version to 8.1 | |||
There was a problem hiding this comment.
You forgot to update the PHP requirement in composer.json to make Composer aware of this bump.
fabpot
force-pushed
the
operator-classes
branch
from
e8a46a6 to
c9cc79d
Compare
…ns instead of arrays
fabpot
force-pushed
the
operator-classes
branch
from
c9cc79d to
df5904e
Compare
fabpot
force-pushed
the
operator-classes
branch
from
94ed9e0 to
65aada2
Compare
fabpot
force-pushed
the
operator-classes
branch
from
65aada2 to
127bffb
Compare
No description provided.