IRC-SPHERE / HyperStream

HyperStream
https://irc-sphere.github.io/HyperStream/
MIT License
13 stars 5 forks source link

Shortcut methods for tools #9

Closed tdiethe closed 7 years ago

tdiethe commented 7 years ago

Currently the tools can now be accessed using shortcut methods: e.g. given a hyperstream instance hs

hs.tools.clock()

and plugins are accessed in a slightly more convoluted way:

hs.plugins.data_generators.tools.random()

This could be changed to make plugins a bit easier to access, at the cost of the core tools, like so:

hs.tools.core.clock()
hs.tools.data_generators.random()

Is this better or should we stick with what we've got?

perellonieto commented 7 years ago

I like the way to differentiate between the basic tools in the HyperStream package from the plugins defined by the final user. I think in that way is easier to understand how to use HyperStream.

However, it is not clear to me why do we need to specify ".tools" inside the plugins. If plugins are just tools, why don't we call them directly with

hs.plugins.data_generators.random()

If you want to have data (like in one of the examples with a CSV file) it makes more sense to have a separate folder with data.

tdiethe commented 7 years ago

The plugins are not just tools: at the very least there are also factors. So I guess the two cases should be:

njtwomey commented 7 years ago

Would it not be more natural to simply recommend the plugin be assigned to a variable:

dg = hs.plugins.data_generators 

hs.tools.clock()  # For core tools 
dg.tools.minchia()  # For plugin tools

This is a pattern that's almost identical to how the memory/mongo/file channels are abstracted, so I think I would advocate for this.

tdiethe commented 7 years ago

Interesting idea, although it could get messy with a lot of plugins around. For example, we already have data_generators and data_importers, and of course in sphere we have our own.

By the channels, I guess you mean when we write:

T = hs.channel_manager.tools
M = hs.channel_manager.memory
D = hs.channel_manager.mongo

etc. I had actually been wondering about this too. The reason you need to do that is because of the way nodes are created - see this issue: #11, which if solved might remove the need to do the above.

tdiethe commented 7 years ago

Closing this ... going to go with @njtwomey's suggestion as this is compatible with the current codebase, is neat enough, and if you have more than a handful of plugins you're probably the most advanced user HyperStream has ever seen!