Dmitriy, I've checked Java implementation of the BinaryType and it seems to be something a bit different than in C++.
Current role of the BinaryType<T> in C++ is to provide Ignite with the information about its template type, to be used during serialization and deserialization. Unlike Java version, C++ BinaryType also used for user to provide implementation of Read and Write methods, i.e. methods that used to serialize and deserialize objects. We can not have non-template interface for this class as Write and Read methods have templated type in theirs signatures: void Write(BinaryWriter& writer, const T& obj); T Read(BinaryReader& reader); We can not change template type T with non-template type as we don't have single root class in C++ like Object class in Java and we also don't have any type information at runtime. Thus we always need to know template type for the BinaryType<T> when we are instantiating it, thus we can not have any fabrics or any polymorphism for this class in C++ and internally we always use default constructor to get new instance of such a class. So, currently I can not see how having non static methods could be useful for this class. Best Regards, Igor On Fri, Jul 22, 2016 at 7:12 PM, Dmitriy Setrakyan <[email protected]> wrote: > I am not a C++ expert, but can you please explain why you would like to > change all methods on the BinaryType to static? Is it the same way in Java? > > On Fri, Jul 22, 2016 at 9:00 AM, Igor Sapego <[email protected]> wrote: > > > Hello Igniters and Ignite users, > > > > As there is going to be Ignite 2.0 release soon, It is a good opportunity > > for us to improve Ignite C++ API without the need to maintain backward > > compatibility. Let's collect and discuss all the proposal for the changes > > in API here. > > > > If you've had any proposal on how to improve C++ API but that could break > > backward compatibility, now you can propose that for us to discuss and > > probably include it in Ignite 2.0. So, go ahead and post your proposals > > here. > > > > Let's create tasks for accepted proposals as subtasks for the task [1] so > > they all could be easy to track. > > > > [1] - https://issues.apache.org/jira/browse/IGNITE-3559 > > > > Best Regards, > > Igor > > >
