New C++11 features may allow us to do away with much of the type heirarchy

[sg-s]

• why do we even have types for each channel type? we rarely if ever make multiple copies of channels
• most of the NaV.hpp file is filler and boilerplate.
• the only actionable information there is setting p, q, and the activation functions

what if, instead conductance was a concrete type, and had fields of type std::function<double(double)> for m_inf, etc? then the "prinz" channels could be specified by instantiating conductance objects, and filling out the functions as needed.

[sg-s]

This is clearly the way to go:

#include <functional>
#include <string>
#include <cmath>
#include <iostream>

using namespace std;

class channel {

int p = 3;
int q = 1;
public:
    string name = "unset";

    double E = 50;
    double g = 0;
    double gbar = 0;

    std::function<double(double)> m_inf;

    channel(double gbar, double E, int p, int q) {
        this->gbar = gbar;
        this->E = E;
        this->p = p;
        this->q = q;
    }

};

namespace prinz {
    double NaV_m_inf(double V) {
        return 1.0/(1.0+exp((V+25.5)/-5.29));
    }
}

int main() {

    channel NaV = channel(100,50,3,1);
    NaV.m_inf = prinz::NaV_m_inf;

    cout << "NaV.m_inf(30) = " << NaV.m_inf(-50) << endl;

}

and we can use the namespace keyword to namespace our channels!

[sg-s]

This allows for a much richer type heirarchy:

• a catch-all conductance class
• a VoltageGatedInactivating class, for e.g., NaV
• a VoltageGatedActivating class for e.g., Kd
• a CalciumGated class for e.g., KCa
• synapses are just conductances that connect to two compartments

Note the m_inf can have different type signatures for each, because conductance doesn't need to know anything about activation functions

[sg-s]

unfortunately MATLAB doesn't support this:

Did not add member 'm_inf' to class 'channel' at channel_test.hpp:20.
  'std::function<double(double)>' as data member or return type not supported.

Did not add member 'h_inf' to class 'channel' at channel_test.hpp:21.
  'std::function<double(double)>' as data member or return type not supported.

[alec-hoyland]

Damn you, two language problem!

[sg-s]

but wait! there's a workaround:

if one writes a setter method, everything is cool

void set_m_inf(string);

and together with a wrapper method that calls m_inf and other dynamically dispatched functions, it mostly mitigates this issue