@@ -68,7 +68,57 @@ import 'piece.dart';
6868/// var [unsplitBlock] =
6969/// longOperand +
7070/// anotherOperand;
71- final class AssignPiece3Dot7 extends Piece {
71+ final class AssignPiece3Dot7 (
72+ /// The `=` or other operator.
73+ final Piece _operator,
74+
75+ // TODO(rnystrom): If it wasn't for the need to constrain [_left] to split
76+ // in [applyConstraints()], we could write the operator into the same piece
77+ // as [_left]. In the common case where the AssignPiece is for a named
78+ // argument, the name and `:` would then end up in a single atomic
79+ // [CodePiece].
80+
81+ /// The right-hand side of the operation.
82+ final Piece _right, {
83+
84+ /// The left-hand side of the operation.
85+ final Piece ? _left,
86+
87+ /// If `true` , then the left side supports being block-formatted, like:
88+ ///
89+ /// var [
90+ /// element1,
91+ /// element2,
92+ /// ] = value;
93+ final bool _canBlockSplitLeft = false ,
94+
95+ /// If `true` then the right side supports being block-formatted, like:
96+ ///
97+ /// var list = [
98+ /// element1,
99+ /// element2,
100+ /// ];
101+ final bool _canBlockSplitRight = false ,
102+
103+ /// If `true` then prefer to split at the operator instead of block splitting
104+ /// the right side.
105+ ///
106+ /// This is `true` for `=>` functions whose body is a function call. This
107+ /// keeps the called function next to its arguments instead having the
108+ /// function name stick to the `=>` while the arguments split. In other words,
109+ /// prefer:
110+ ///
111+ /// someMethod() =>
112+ /// someFunction(argument, another);
113+ ///
114+ /// Over:
115+ ///
116+ /// someMethod() => someFunction(
117+ /// argument,
118+ /// another,
119+ /// );
120+ final bool _avoidBlockSplitRight = false ,
121+ }) extends Piece {
72122 /// Force the block left-hand side to split and allow the right-hand side to
73123 /// split.
74124static const State _blockSplitLeft = State (1 );
@@ -79,58 +129,6 @@ final class AssignPiece3Dot7 extends Piece {
79129 /// Split at the operator.
80130static const State _atOperator = State (3 );
81131
82- this (
83- /// The `=` or other operator.
84- final Piece _operator,
85-
86- // TODO(rnystrom): If it wasn't for the need to constrain [_left] to split
87- // in [applyConstraints()], we could write the operator into the same piece
88- // as [_left]. In the common case where the AssignPiece is for a named
89- // argument, the name and `:` would then end up in a single atomic
90- // [CodePiece].
91-
92- /// The right-hand side of the operation.
93- final Piece _right, {
94-
95- /// The left-hand side of the operation.
96- final Piece ? _left,
97-
98- /// If `true` , then the left side supports being block-formatted, like:
99- ///
100- /// var [
101- /// element1,
102- /// element2,
103- /// ] = value;
104- final bool _canBlockSplitLeft = false ,
105-
106- /// If `true` then the right side supports being block-formatted, like:
107- ///
108- /// var list = [
109- /// element1,
110- /// element2,
111- /// ];
112- final bool _canBlockSplitRight = false ,
113-
114- /// If `true` then prefer to split at the operator instead of block splitting
115- /// the right side.
116- ///
117- /// This is `true` for `=>` functions whose body is a function call. This
118- /// keeps the called function next to its arguments instead having the
119- /// function name stick to the `=>` while the arguments split. In other words,
120- /// prefer:
121- ///
122- /// someMethod() =>
123- /// someFunction(argument, another);
124- ///
125- /// Over:
126- ///
127- /// someMethod() => someFunction(
128- /// argument,
129- /// another,
130- /// );
131- final bool _avoidBlockSplitRight = false ,
132- });
133-
134132 @override
135133 List <State > get additionalStates => [
136134 // If at least one operand can block split, allow splitting in operands
0 commit comments