Introduce Interfaces

[breznak]

so that code can be more cleanly used, code redux.
Interfaces enforce stable API, name form of *able.

• Computable
  • feed forward compute input
  • void compute(T* input, T* output)
  • will be used for all classes: encoder, SP, TM*, Anomaly, ...
• Serializable
  • can serialize to file
  • void save(..) throws;
  • static T load(..)
• Printable
  • nice way to display the object in human readable form
  • std::string toString() const
  • override << ..?
• Comparable
  • implements equals comparison
  • override ==

[dkeeney]

The API is specified in the API documents. Particularly the Plugin interface which are those classes that are sub-classes of RegionImpl. It is through the plugins that the Network framework accesses the algorithm modules. I agree we can make the algorithm modules more friendly but lets not change the way the plugin works...we would break a lot of things.

…

On Tue, Aug 14, 2018 at 2:17 AM breznak ***@***.***> wrote: so that code can be more cleanly used, code redux. Interfaces enforce stable API, name form of *able. - Computable - feed forward compute input - void compute(T* input, T* output) - will be used for all classes: encoder, SP, TM*, Anomaly, ... - Serializable - can serialize to file - void save(..) throws; - static T load(..) - Printable - nice way to display the object in human readable form - std::string toString() const - override << ..? - Comparable - implements equals comparison - override == — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#58>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBa_8V941zMoKT0lDQhod1MR3niKbRRks5uQpWYgaJpZM4V8EsQ> .

[breznak]

hmm..I'll study the docs for Network API, though this task was to introduce this (OOP) logic into the core algorithms (not Regions). Result would be cleaner, better maintainable code, which would be easier to use directly. Eg:

for( Serializable s : {myEnc, mySP, myTM}) 
  s.save(...);

I hope this change could be implemented without breaking the (higher-level) Region/Network API (?)

[dkeeney]

My feeling is that we do not want to break any python code and python code can address both the Network API and individual algorithms. I had some degree of freedom with the C++ version of BacktrackingTMCpp because I know there is no python code calling it yet but everything else we need to be careful of.

…

On Tue, Aug 14, 2018 at 7:16 AM breznak ***@***.***> wrote: hmm..I'll study the docs for Network API, though this task was to introduce this (OOP) logic into the core algorithms (not Regions). Result would be cleaner, better maintainable code, which would be easier to use directly. Eg: for( Serializable s : {myEnc, mySP, myTM}) s.save(...); I hope this change could be implemented without breaking the (higher-level) Region/Network API (?) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBa_2Gba9dulKfgwDD5zXIATt1Hq5yhks5uQtu2gaJpZM4V8EsQ> .

[breznak]

My feeling is that we do not want to break any python code and python code can address both the Network API and individual algorithms.

Good point, hadn't thought about that.
We could either provide interfaces in the python-wrapper code, or even at c++ level, where the "old API" method would call the "correct". This API can be marked for depracation later. (I start to like this approach, esp with an ifdef #OLD_API_vX.Y) This could allow c++ folks to loosen the depdendency on py (other) old compatibility, while still supporting it for respective (most) users. Loosening c++ and the bindings is one of the big goals now..

[dkeeney]

I agree. However, I have seen other projects where the #ifdef OLD_API statements so cluttered the code that it was almost unreadable. So we need to use those carefully and only when we must. For now let's just get the code working.

…

On Tue, Aug 14, 2018 at 8:57 AM breznak ***@***.***> wrote: My feeling is that we do not want to break any python code and python code can address both the Network API and individual algorithms. Good point, hadn't thought about that. We could either provide interfaces in the python-wrapper code, or even at c++ level, where the "old API" method would call the "correct". This API can be marked for depracation later. (I start to like this approach, esp with an ifdef #OLD_API_vX.Y) This could allow c++ folks to loosen the depdendency on py (other) old compatibility, while still supporting it for respective (most) users. Loosening c++ and the bindings is one of the big goals now.. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBa_2XwRoa3VmQNR5f60nD6jqH-8QVLks5uQvNsgaJpZM4V8EsQ> .

[breznak]

Serializable re-implemented as part of capnp removal in #62 !

[breznak]

currently it's in types/Serializable, should we introduce something like interfaces/ for better structure of the repo?

[dkeeney]

There are so few interfaces that it is probably not worth making the change. If we get a lot of interfaces then it might make since.

…

On Wed, Sep 19, 2018 at 2:26 AM breznak ***@***.***> wrote: currently it's in types/Serializable, should we introduce something like interfaces/ for better structure of the repo? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBa_0hFZxuciifz608XywiVLRxQqCtQks5ucg3XgaJpZM4V8EsQ> .