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:02:00 UTC
[jira] [Created] (CALCITE-4311) Add non-nullable experimental
accessors side by side with their nullable counterparts
Vladimir Sitnikov created CALCITE-4311:
------------------------------------------
Summary: 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
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)