Re: [RFC LNST 0/4] create functions without logic in run time
On Mon, Oct 31, 2016 at 12:34:17PM +0200, Nogah Frankel wrote:
When one want to add a new function to the slave, one needs to add it
also
to the slave communicator (NetTestSlave), and to the controller side that
control it (Macine) and to Task, that controls it.
While some of this functions have logic, most of them are just calling a
function of an object that they holds, usually, with the same name.
Those function can, and I think they should, be manufactured in run time
for the following reasons:
* it shorten the code considerably (new code is 25% of the old one).
* it makes adding new function much shorter.
* it singles out the function that do have logic in them.
There are however some down sides to it:
* code is a bit harder to read at first.
* Inheriting function is a bit more tricky.
This is just a start and it can be expanded for:
* more classes with functions with this problem
* setter-getters without inner logic
* function with arguments with default values
I know that LNST is now in freeze and I don't know how much of it will be
relevant after it. But in case it is, I will be glad to hear your
opinions on it in the meantime.
Nogah Frankel (4):
Machine: Interface: create RPC calls functions in run time
Slave: NetTestSlave: SlaveMethods: create dev functions calls in run
time
Slave: NetTestSlave: SlaveMethods: create bridge function calls in run
time
Task: InterfaceAPI: create interface calls functions in run time
lnst/Controller/Machine.py | 106 ++++-----------
lnst/Controller/Task.py | 93 ++++---------
lnst/Slave/NetTestSlave.py | 326 +++++++++------------------------------------
3 files changed, 113 insertions(+), 412 deletions(-)
--
2.4.3
_______________________________________________
LNST-developers mailing list -- lnst-developers(a)lists.fedorahosted.org
To unsubscribe send an email to lnst-developers-leave(a)lists.fedorahosted.org
Hi,
I further discussed this with jpirko after last weeks meeting, and came
to the conclusion that we only want to have 2 branches - master and
next. master will stay frozen for now, accepting only fixes or new
recipes and next is where we can put new experiments.
So if you want to apply this patchset to upstream, it would have to be
rebased on top of the current next branch. Is that ok?
Meanwhile, I've finished updating the wiki and I'm going to work on the
next branch from this week on. As discussed, I'll start by creating
specifications for the new API, based on our previous discussions. From
now on I should be fully focused on getting Python Recipes ready.
-Ondrej