-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
GH-37234: [MATLAB] Create an abstract arrow.type.TemporalType
class
#37236
Conversation
Co-authored-by: Kevin Gurney <kgurney@mathworks.com>
…d timeZone() to getTimeZone() Co-authored-by: Kevin Gurney <kgurney@mathworks.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
After merging your PR, Conbench analyzed the 5 benchmarking runs that have been run so far on merge-commit 5abdc6e. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them. |
### Rationale for this change The original motivation for adding the super-class `arrow.type.TemporalType` in #37236 was to define a common implementation for extracting the `Unit` property from `TimestampType`, `Time32Type`, `Time64Type`, `Date32Type`, and `Date64Type`. However, this approach doesn't work because the `Unit` property on `Date32Type` and `Date64Type` is a `DateUnit`, while the `Unit` property on the other three types is a`TimeUnit`. As a result, we cannot define a shared method for extracting the `Unit` property in `TemporalType`. Instead, we plan on making `arrow.type.TemporalType` a "tag"-class (i.e. it has no properties or methods) so it can be used to group the "temporal" types together to ease authoring conditional logical in client code. In a future PR, we plan on adding functions like `arrow.type.isTemporal`, `arrow.type.isNumeric`, etc. so that clients don't need to query the class type information directly (i.e. call `isa(type, "arrow.type.TemporalType")`). ```matlab function doStuff(arrowArray) import arrow.* arrowType = arrowArray.Type; if type.isTemporal(arrowType) ... else if type.isNumeric(arrowType) ... else ... end end ``` ### What changes are included in this PR? 1. Removed the `TimeUnit` property from `arrow.type.TemporalType` 2. Added `TimeUnit` back as a property on `arrow.type.TimestampType` and `arrow.type.Time32Type` ### Are these changes tested? Yes, the existing tests cover these changes. ### Are there any user-facing changes? No. ### Future Directions 1. #37232 2. #37229 3. #37230 * Closes: #37251 Authored-by: Sarah Gilmore <sgilmore@mathworks.com> Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
… class (apache#37236) ### Rationale for this change To simplify the implementation of `Time32Type`, `Time64Type`, `Date32Type`, and `Date64Type`, it would be helpful to create an abstract `arrow.type.TemporalType` class that the date and time types can inherit from. As a first step, we can modify the implementation of `TimestampType` to inherit from `TemporalType`. This mimics the class inheritance hierarchy from the C++ libraries. ### What changes are included in this PR? 1. Added a new MATLAB class called `arrow.type.TemporalType`. It inherits from `arrow.type.FixedWidthType` and defines one read-only property: `TimeUnit`. 2. Modified the MATLAB class `arrow.type.TimestampType` to inherit from `arrow.type.TemporalType` instead of `arrow.type.FixedWidthType`. 3. Renamed the C++ `proxy::TimestampType` methods `timeUnit()` and `timeZone()` to `getTimeUnit()` and `getTimeZone()`. ### Are these changes tested? Yes. The existing tests in `tTimetampType.m` cover these changes. ### Are there any user-facing changes? No. ### Future Directions 1. Add `arrow.type.Time32Type` (apache#37231) 2. Add `arrow.type.Time64Type` (apache#37225) 3. Add `arrow.type.Date32Type` (apache#37229), 4. Add `arrow.type.Time64Type` (apache#37230). 5. Add `arrow.array.Time32Array` 6. Add `arrow.array.Time64Array` 7. Add `arrow.array.Date32Array` 8. Add `arrow.array.Date64Array` * Closes: apache#37234 Lead-authored-by: Sarah Gilmore <sgilmore@mathworks.com> Co-authored-by: Kevin Gurney <kgurney@mathworks.com> Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
…apache#37256) ### Rationale for this change The original motivation for adding the super-class `arrow.type.TemporalType` in apache#37236 was to define a common implementation for extracting the `Unit` property from `TimestampType`, `Time32Type`, `Time64Type`, `Date32Type`, and `Date64Type`. However, this approach doesn't work because the `Unit` property on `Date32Type` and `Date64Type` is a `DateUnit`, while the `Unit` property on the other three types is a`TimeUnit`. As a result, we cannot define a shared method for extracting the `Unit` property in `TemporalType`. Instead, we plan on making `arrow.type.TemporalType` a "tag"-class (i.e. it has no properties or methods) so it can be used to group the "temporal" types together to ease authoring conditional logical in client code. In a future PR, we plan on adding functions like `arrow.type.isTemporal`, `arrow.type.isNumeric`, etc. so that clients don't need to query the class type information directly (i.e. call `isa(type, "arrow.type.TemporalType")`). ```matlab function doStuff(arrowArray) import arrow.* arrowType = arrowArray.Type; if type.isTemporal(arrowType) ... else if type.isNumeric(arrowType) ... else ... end end ``` ### What changes are included in this PR? 1. Removed the `TimeUnit` property from `arrow.type.TemporalType` 2. Added `TimeUnit` back as a property on `arrow.type.TimestampType` and `arrow.type.Time32Type` ### Are these changes tested? Yes, the existing tests cover these changes. ### Are there any user-facing changes? No. ### Future Directions 1. apache#37232 2. apache#37229 3. apache#37230 * Closes: apache#37251 Authored-by: Sarah Gilmore <sgilmore@mathworks.com> Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
Rationale for this change
To simplify the implementation of
Time32Type
,Time64Type
,Date32Type
, andDate64Type
, it would be helpful to create an abstractarrow.type.TemporalType
class that the date and time types can inherit from.As a first step, we can modify the implementation of
TimestampType
to inherit fromTemporalType
.This mimics the class inheritance hierarchy from the C++ libraries.
What changes are included in this PR?
arrow.type.TemporalType
. It inherits fromarrow.type.FixedWidthType
and defines one read-only property:TimeUnit
.arrow.type.TimestampType
to inherit fromarrow.type.TemporalType
instead ofarrow.type.FixedWidthType
.proxy::TimestampType
methodstimeUnit()
andtimeZone()
togetTimeUnit()
andgetTimeZone()
.Are these changes tested?
Yes. The existing tests in
tTimetampType.m
cover these changes.Are there any user-facing changes?
No.
Future Directions
arrow.type.Time32Type
([MATLAB] Addarrow.type.Time32Type
class andarrow.time32
construction function #37231)arrow.type.Time64Type
([MATLAB] Addarrow.type.Time64Type
class andarrow.time64
construction function #37232)arrow.type.Date32Type
([MATLAB] Addarrow.type.Date32Type
class andarrow.date32
construction function #37229),arrow.type.Time64Type
([MATLAB] Addarrow.type.Date64Type
class andarrow.date64
construction function #37230).arrow.array.Time32Array
arrow.array.Time64Array
arrow.array.Date32Array
arrow.array.Date64Array
arrow.type.TemporalType
class #37234