You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Vladimir Sitnikov (Jira)" <ji...@apache.org> on 2020/10/05 14:17:00 UTC

[jira] [Commented] (CALCITE-4311) Add non-nullable experimental accessors side by side with their nullable counterparts

    [ https://issues.apache.org/jira/browse/CALCITE-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208099#comment-17208099 ] 

Vladimir Sitnikov commented on CALCITE-4311:
--------------------------------------------

Sample candidates for non-nullable getters: https://github.com/vlsi/calcite/blob/checkerframework/core/src/main/java/org/apache/calcite/sql/validate/SqlNonNullableAccessors.java , https://github.com/vlsi/calcite/blob/checkerframework/core/src/main/java/org/apache/calcite/sql/type/NonNullableAccessors.java

[~julianhyde], [~danny0405], what do you think of something like the following?

{code:java}
public interface Wrapper {
  /** Finds an instance of an interface implemented by this object,
   * or returns null if this object does not support that interface. */
  <C extends @NonNull Object> @Nullable C unwrap(Class<C> aClass);

  /** Finds an instance of an interface implemented by this object,
   * or throws NullPointerException if this object does not support
   * that interface. */
  @API(since = "1.27", status = API.Status.INTERNAL)
  default <C extends @NonNull Object> C unwrapNonNull(Class<C> aClass) {
    return requireNonNull(unwrap(aClass),
        () -> "Can't unwrap " + aClass + " from " + this);
  }
}
{code}

> Add non-nullable experimental accessors side by side with their nullable counterparts
> -------------------------------------------------------------------------------------
>
>                 Key: CALCITE-4311
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4311
>             Project: Calcite
>          Issue Type: Sub-task
>    Affects Versions: 1.25.0
>            Reporter: Vladimir Sitnikov
>            Priority: Major
>
> Certain APIs are declared to return nullable values, however, they are often used in "I know this must be non-null" context.
> For instance: {{Wrapper#unwrap(Class)}}.
> It happens so that {{.unwrap(Table.class)}} is quite common.
> For instance:
> {code:java}
>             final Table leftTable = leftRelOptTable.unwrap(Table.class);
>             final int leftCount = leftRelOptTable.getRowType().getFieldCount();
> {code}
> It would be nice if unwrap could fail with a proper message like "oh, I can't find Table in ...", so the end users would get better error messages, and the code would be way easier to read.
> For instance:
> {code:java}
> // unwrapNonNull can be declared as a default implementation
>             final Table leftTable = leftRelOptTable.unwrapNonNull(Table.class);
>             final int leftCount = leftRelOptTable.getRowType().getFieldCount();
> {code}
> ---
> Another case is {{org.apache.calcite.sql.SqlSelect#getSelectList}}. The method returns a nullable value, however, it is often used as if it was non-nullable.
> Initially, I thought of adding static helper methods to utility classes/interfaces, however, now I'm inlined to adding non-nullable getters right to the original classes/interfaces.
> That would make the code easier to read and write.
> ---
> Another quite common case is metadata: sometimes users need non-null value for the metadata, so it would be nice to have a default value via argument or throw in case of missing metadata.
> See CALCITE-4215



--
This message was sent by Atlassian Jira
(v8.3.4#803005)