You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Igor Sapego <is...@gridgain.com> on 2016/07/22 16:00:31 UTC
Breaking improvements for the Ignite C++.
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
Re: Breaking improvements for the Ignite C++.
Posted by Igor Sapego <is...@gridgain.com>.
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 <ds...@apache.org>
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 <is...@gridgain.com> 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
> >
>
Re: Breaking improvements for the Ignite C++.
Posted by Igor Sapego <is...@gridgain.com>.
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 <ds...@apache.org>
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 <is...@gridgain.com> 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
> >
>
Re: Breaking improvements for the Ignite C++.
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <is...@gridgain.com> 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
>
Re: Breaking improvements for the Ignite C++.
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <is...@gridgain.com> 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
>