felipecrv commented on issue #38204:
URL: https://github.com/apache/arrow/issues/38204#issuecomment-1771076054

   > used inconsistently and whose relationships and specific semantics are not 
really documented. 
   
   We can document them (!) with a publishable version of this:
   
   
![image](https://github.com/apache/arrow/assets/207795/ea1bd401-fb9b-4307-acad-a4722ab1db66)
   
   > These have been added ad-hoc as they were needed rather than 
systematically laid out
   
   After I laid them out in the graph above there are only a few things I would 
change because I think the predicates actually follow a neat hierarchy:
   
    - Drop all the predicates that use `std::is_base_of` and define them either 
via other predicates or explicit enumeration of the types
    - Remove the two DEPRECATED predicates/traits:`is_base_list_type` and 
`enable_if_base_list`
    - Drop the substring "size" from some list-related traits and use only 
`length`
   
   > I think instead of trying to construct them in reflection the class 
hierarchy of DataType is only indirectly useful; what we actually use these to 
check for is ...
   
   Sometimes we want to test whether a type belongs to an explicit definition 
of a set and sometimes we want to test for a property. There are uses for both. 
This is a classic debate in Logic [1].
   
   One problem with predicates that test for a property (extensional equality) 
is that the set of types keeps growing and we can't know for sure existing 
kernel implementations outside of our control are not assuming other properties 
from the predicates we currently provide. If we had a "has offsets" predicate, 
we would be tempted to include list-views on that, but almost surely that would 
make code written based on that property break because that code probably also 
assumes that the offsets would be sorted. We would end-up with a confusing "has 
offsets" in the codebase with a big warning telling people that it can't be 
extended to list-views.
   
   I think a good contract to honor in `type_traits.h` is to rarely include 
predicates that can be expanded: all the predicates define sets that we can 
enumerate easily. When I added the new list-view related predicates, I only 
expanded the `is_nested` predicate which I think is generic enough that when 
people use it, they don't assume much (🤞).
   
   [1] https://en.wikipedia.org/wiki/Extensionality


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to