Github user dawidwys commented on a diff in the pull request:
https://github.com/apache/flink/pull/6312#discussion_r201844991
--- 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 --
It is a basic Visitor Pattern approach. This way we have a typesafe way of
implementing it. With the enum approach we would need to do casting if we have
any custom parameters e.g. in link where beside link we also want to have a
visible name for the link.
Also I would be in favour of splitting into inline and block elements to
control complexity of the structure. I don't think we should support highly
nested structures just to minimize future efforts.
---
