hi Josh,

Thank you for putting together this document. These changes are
interesting and worth giving some consideration. Some initial
reactions / questions to get a discussion going:

* How is MSVC support for covariant return types? It doesn't look like
it's supported, which (I'm sorry to say) would be a deal breaker
https://msdn.microsoft.com/en-us/library/8z9feath.aspx
* I don't think creating a situation where arrow::DataType objects
have to be copied is a good idea. Schemas and types will be reused,
particular in a streaming data setting
* Adding a covariant shared_ptr seems very complicated; it seems the
primary benefit will be in code where we would currently have to
introduce a dynamic visitor pattern. Could the same benefit be reaped
by adding a _new_ virtual base method that returns a pointer or
const-ref to the concrete type? This is a less invasive change
* I think it is beneficial to have a simple internal data structure
(i.e. ArrayData) that describes any Arrow array object

>From reading this document, I am wondering if it would not be worth
thinking about creating a from-scratch set of array and type data
structures intended for use in a static / compile-time setting. Since
Arrow features "dynamic" schemas (in the sense that Avro is a more
dynamic version of Protocol Buffers or Thrift), we inevitably will be
dealing with the problem of dynamic dispatch from type information
known only at runtime. I agree that it would be useful to eliminate
usages of dynamic visitor pattern in the codebase where possible.

- Wes

On Sat, May 19, 2018 at 12:48 AM, joshuasto...@gmail.com
<joshuasto...@gmail.com> wrote:
> I've put together a proposal for using covariant return types in 
> Array::type() in the C++ library. I wanted to get some feedback before 
> putting together a PR in case it's too controversial or would require to much 
> re-factoring of the code:
>
> https://docs.google.com/document/d/14mLO9uNIcrb-yTj_byBxwJeYbGy88JS9fQ6aOa46XRc/edit?usp=sharing
>
> It would be nice to use Google Doc's comment feature, but I would imagine it 
> may be safer to memorialize the discussion here on the mailing list.

Reply via email to