flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dawidwys <...@git.apache.org>
Subject [GitHub] flink pull request #6312: [FLINK-9792] Added custom Description class for Co...
Date Thu, 12 Jul 2018 07:55:26 GMT
Github user dawidwys commented on a diff in the pull request:

    --- 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
    I am afraid we end up in a preference lockdown.


View raw message