Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MATLAB] Add a MATLAB "type traits" class hierarchy #36601

Closed
kevingurney opened this issue Jul 10, 2023 · 0 comments · Fixed by #36653
Closed

[MATLAB] Add a MATLAB "type traits" class hierarchy #36601

kevingurney opened this issue Jul 10, 2023 · 0 comments · Fixed by #36653

Comments

@kevingurney
Copy link
Member

kevingurney commented Jul 10, 2023

Describe the enhancement requested

To make it easier to write generic code for arrow.array.Array and associated objects in the MATLAB interface, it would be helpful to have some kind of "type traits"-like objects (e.g. arrow.type.traits.StringTraits, arrow.type.traits.UInt8Traits, etc.).

These "type traits" objects would help centralize various type-specific information in one place (e.g. MATLAB double <-> arrow.type.Float64Type <-> arrow.array.Float64Array), simplifying generic client code.

This would help reduce the number of "switch-like" statements across the MATLAB code base that branch based on type.

Component(s)

MATLAB

@kevingurney kevingurney self-assigned this Jul 10, 2023
kevingurney added a commit that referenced this issue Jul 13, 2023
### Rationale for this change

To make it easier to write generic code for `arrow.array.Array` and associated objects in the MATLAB interface, it would be helpful to have some kind of ["type traits"-like](https://github.com/apache/arrow/blob/d676078c13a02ad920eeea2acd5fa517f14526e2/cpp/src/arrow/type_traits.h#L105) objects (e.g. `arrow.type.traits.StringTraits`, `arrow.type.traits.UInt8Traits`, etc.).

These "type traits" objects would help centralize various type-specific information in one place (e.g. MATLAB `double` <-> `arrow.type.Float64Type` <-> `arrow.array.Float64Array`), simplifying generic client code.

This would help reduce the number of "switch-like" statements across the MATLAB code base that branch based on type.

### What changes are included in this PR?

1. Added new `arrow.type.traits.TypeTraits` classes (e.g. `arrow.type.traits.UInt8Traits` and `arrow.type.traits.StringTraits`).
2. Added new `arrow.type.traits.traits` "gateway" function for creating "type traits" objects from MATLAB class strings (e.g. `"double"` or `"datetime"`) and `arrow.type.ID` enumeration values (e.g. `arrow.type.ID.Timestamp` or `arrow.type.ID.UInt8`).

### Are these changes tested?

Yes.

1. Added MATLAB tests for the new `arrow.type.traits.TypeTraits` classes.
2. Added MATLAB tests  (`ttraits.m`) for the new `arrow.type.traits.traits` "gateway" function. 

### Are there any user-facing changes?

Yes.

There are now MATLAB "type traits" classes that can be used to simplify writing generic client code that switches based on type.

**Note**: It may make sense to eventually mark these "type traits" APIs as "internal" so that they aren't encouraged to be used by client code outside of the MATLAB interface. The "type traits" classes expose some implementation details such as the `Proxy` classes that are used under the hood to represent a given `Array` object in C++.

**Example**

```matlab
% Construct a "type traits" object from an arrow.type.ID enumeration value
>> logicalTraits = arrow.type.traits.traits(arrow.type.ID.Boolean)

logicalTraits = 

  BooleanTraits with properties:

       ArrayConstructor: @ arrow.array.BooleanArray
         ArrayClassName: "arrow.array.BooleanArray"
    ArrayProxyClassName: "arrow.array.proxy.BooleanArray"
        TypeConstructor: @ arrow.type.BooleanType
          TypeClassName: "arrow.type.BooleanType"
     TypeProxyClassName: "arrow.type.proxy.BooleanType"
      MatlabConstructor: @ logical
        MatlabClassName: "logical"

% Construct a "type traits" object from a MATLAB class string
>> stringTraits = arrow.type.traits.traits("string")

stringTraits = 

  StringTraits with properties:

       ArrayConstructor: @ arrow.array.StringArray
         ArrayClassName: "arrow.array.StringArray"
    ArrayProxyClassName: "arrow.array.proxy.StringArray"
        TypeConstructor: @ arrow.type.StringType
          TypeClassName: "arrow.type.StringType"
     TypeProxyClassName: "arrow.type.proxy.StringType"
      MatlabConstructor: @ string
        MatlabClassName: "string"
```

### Future Directions

1. Re-implement `switch` statement in `RecordBatch` code to use "type traits" classes instead.
2. Look for more opportunties to leverage "type traits" to simplify code in the MATLAB interface.

### Notes

1. Thanks @ sgilmore10 for your help with this pull request! 
* Closes: #36601

Lead-authored-by: Kevin Gurney <kgurney@mathworks.com>
Co-authored-by: Sarah Gilmore <sgilmore@mathworks.com>
Co-authored-by: Fiona La <fionala7@gmail.com>
Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
@kevingurney kevingurney added this to the 14.0.0 milestone Jul 13, 2023
chelseajonesr pushed a commit to chelseajonesr/arrow that referenced this issue Jul 20, 2023
…pache#36653)

### Rationale for this change

To make it easier to write generic code for `arrow.array.Array` and associated objects in the MATLAB interface, it would be helpful to have some kind of ["type traits"-like](https://github.com/apache/arrow/blob/d676078c13a02ad920eeea2acd5fa517f14526e2/cpp/src/arrow/type_traits.h#L105) objects (e.g. `arrow.type.traits.StringTraits`, `arrow.type.traits.UInt8Traits`, etc.).

These "type traits" objects would help centralize various type-specific information in one place (e.g. MATLAB `double` <-> `arrow.type.Float64Type` <-> `arrow.array.Float64Array`), simplifying generic client code.

This would help reduce the number of "switch-like" statements across the MATLAB code base that branch based on type.

### What changes are included in this PR?

1. Added new `arrow.type.traits.TypeTraits` classes (e.g. `arrow.type.traits.UInt8Traits` and `arrow.type.traits.StringTraits`).
2. Added new `arrow.type.traits.traits` "gateway" function for creating "type traits" objects from MATLAB class strings (e.g. `"double"` or `"datetime"`) and `arrow.type.ID` enumeration values (e.g. `arrow.type.ID.Timestamp` or `arrow.type.ID.UInt8`).

### Are these changes tested?

Yes.

1. Added MATLAB tests for the new `arrow.type.traits.TypeTraits` classes.
2. Added MATLAB tests  (`ttraits.m`) for the new `arrow.type.traits.traits` "gateway" function. 

### Are there any user-facing changes?

Yes.

There are now MATLAB "type traits" classes that can be used to simplify writing generic client code that switches based on type.

**Note**: It may make sense to eventually mark these "type traits" APIs as "internal" so that they aren't encouraged to be used by client code outside of the MATLAB interface. The "type traits" classes expose some implementation details such as the `Proxy` classes that are used under the hood to represent a given `Array` object in C++.

**Example**

```matlab
% Construct a "type traits" object from an arrow.type.ID enumeration value
>> logicalTraits = arrow.type.traits.traits(arrow.type.ID.Boolean)

logicalTraits = 

  BooleanTraits with properties:

       ArrayConstructor: @ arrow.array.BooleanArray
         ArrayClassName: "arrow.array.BooleanArray"
    ArrayProxyClassName: "arrow.array.proxy.BooleanArray"
        TypeConstructor: @ arrow.type.BooleanType
          TypeClassName: "arrow.type.BooleanType"
     TypeProxyClassName: "arrow.type.proxy.BooleanType"
      MatlabConstructor: @ logical
        MatlabClassName: "logical"

% Construct a "type traits" object from a MATLAB class string
>> stringTraits = arrow.type.traits.traits("string")

stringTraits = 

  StringTraits with properties:

       ArrayConstructor: @ arrow.array.StringArray
         ArrayClassName: "arrow.array.StringArray"
    ArrayProxyClassName: "arrow.array.proxy.StringArray"
        TypeConstructor: @ arrow.type.StringType
          TypeClassName: "arrow.type.StringType"
     TypeProxyClassName: "arrow.type.proxy.StringType"
      MatlabConstructor: @ string
        MatlabClassName: "string"
```

### Future Directions

1. Re-implement `switch` statement in `RecordBatch` code to use "type traits" classes instead.
2. Look for more opportunties to leverage "type traits" to simplify code in the MATLAB interface.

### Notes

1. Thanks @ sgilmore10 for your help with this pull request! 
* Closes: apache#36601

Lead-authored-by: Kevin Gurney <kgurney@mathworks.com>
Co-authored-by: Sarah Gilmore <sgilmore@mathworks.com>
Co-authored-by: Fiona La <fionala7@gmail.com>
Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
R-JunmingChen pushed a commit to R-JunmingChen/arrow that referenced this issue Aug 20, 2023
…pache#36653)

### Rationale for this change

To make it easier to write generic code for `arrow.array.Array` and associated objects in the MATLAB interface, it would be helpful to have some kind of ["type traits"-like](https://github.com/apache/arrow/blob/d676078c13a02ad920eeea2acd5fa517f14526e2/cpp/src/arrow/type_traits.h#L105) objects (e.g. `arrow.type.traits.StringTraits`, `arrow.type.traits.UInt8Traits`, etc.).

These "type traits" objects would help centralize various type-specific information in one place (e.g. MATLAB `double` <-> `arrow.type.Float64Type` <-> `arrow.array.Float64Array`), simplifying generic client code.

This would help reduce the number of "switch-like" statements across the MATLAB code base that branch based on type.

### What changes are included in this PR?

1. Added new `arrow.type.traits.TypeTraits` classes (e.g. `arrow.type.traits.UInt8Traits` and `arrow.type.traits.StringTraits`).
2. Added new `arrow.type.traits.traits` "gateway" function for creating "type traits" objects from MATLAB class strings (e.g. `"double"` or `"datetime"`) and `arrow.type.ID` enumeration values (e.g. `arrow.type.ID.Timestamp` or `arrow.type.ID.UInt8`).

### Are these changes tested?

Yes.

1. Added MATLAB tests for the new `arrow.type.traits.TypeTraits` classes.
2. Added MATLAB tests  (`ttraits.m`) for the new `arrow.type.traits.traits` "gateway" function. 

### Are there any user-facing changes?

Yes.

There are now MATLAB "type traits" classes that can be used to simplify writing generic client code that switches based on type.

**Note**: It may make sense to eventually mark these "type traits" APIs as "internal" so that they aren't encouraged to be used by client code outside of the MATLAB interface. The "type traits" classes expose some implementation details such as the `Proxy` classes that are used under the hood to represent a given `Array` object in C++.

**Example**

```matlab
% Construct a "type traits" object from an arrow.type.ID enumeration value
>> logicalTraits = arrow.type.traits.traits(arrow.type.ID.Boolean)

logicalTraits = 

  BooleanTraits with properties:

       ArrayConstructor: @ arrow.array.BooleanArray
         ArrayClassName: "arrow.array.BooleanArray"
    ArrayProxyClassName: "arrow.array.proxy.BooleanArray"
        TypeConstructor: @ arrow.type.BooleanType
          TypeClassName: "arrow.type.BooleanType"
     TypeProxyClassName: "arrow.type.proxy.BooleanType"
      MatlabConstructor: @ logical
        MatlabClassName: "logical"

% Construct a "type traits" object from a MATLAB class string
>> stringTraits = arrow.type.traits.traits("string")

stringTraits = 

  StringTraits with properties:

       ArrayConstructor: @ arrow.array.StringArray
         ArrayClassName: "arrow.array.StringArray"
    ArrayProxyClassName: "arrow.array.proxy.StringArray"
        TypeConstructor: @ arrow.type.StringType
          TypeClassName: "arrow.type.StringType"
     TypeProxyClassName: "arrow.type.proxy.StringType"
      MatlabConstructor: @ string
        MatlabClassName: "string"
```

### Future Directions

1. Re-implement `switch` statement in `RecordBatch` code to use "type traits" classes instead.
2. Look for more opportunties to leverage "type traits" to simplify code in the MATLAB interface.

### Notes

1. Thanks @ sgilmore10 for your help with this pull request! 
* Closes: apache#36601

Lead-authored-by: Kevin Gurney <kgurney@mathworks.com>
Co-authored-by: Sarah Gilmore <sgilmore@mathworks.com>
Co-authored-by: Fiona La <fionala7@gmail.com>
Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant