Github user dawidwys commented on a diff in the pull request:
https://github.com/apache/flink/pull/6312#discussion_r201940611
--- Diff:
flink-core/src/main/java/org/apache/flink/configuration/description/LineBreakElement.java
---
@@ -0,0 +1,40 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.flink.configuration.description;
+
+/**
+ * Represents a line break in the {@link Description}.
+ */
+public class LineBreakElement implements BlockElement {
+
+ /**
+ * Creates a line break in the description.
+ */
+ public static LineBreakElement linebreak() {
+ return new LineBreakElement();
+ }
+
+ private LineBreakElement() {
+ }
+
+ @Override
+ public String format(Formatter formatter) {
+ return formatter.format(this);
--- End diff --
As for the infinite nesting I could do exactly the same with the Visitor
Pattern approach and introduce `Sequence` class. Both approaches are exactly
the same in case of class hierarchy. It is just the question of how do we do a
pattern matching - formatting. In languages with pattern matching on class type
it is straightforward and we would go for a switch that would do a safe type
inference.
In java we have two options Visitor pattern(my suggestion), switch on
enum(your suggestion). I feel we are down to personal preference on that matter.
Why do I prefer the first one is that the classes are made to measure. They
reflect structure of element: no empty methods, if unnecessary - e.g. no
`getValue` in `LineBreak`, no `getChildren` methods in `InlineElements`, can
have specialized fields in elements e.g. description for link, maybe importance
for heading (h1-h6), could add number of line breaks into a single element.
I am afraid we end up in a preference lockdown.
---
