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.
