Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parameter implementation design #419

Open
tablatronix opened this issue Sep 10, 2017 · 7 comments
Open

parameter implementation design #419

tablatronix opened this issue Sep 10, 2017 · 7 comments
Labels
Question User Question member to member support

Comments

@tablatronix
Copy link
Collaborator

Am I the only one that doesn't really like the way parameters are implemented ?
I am not sure how I feel about the design pattern used, maye there was a reason, it just seems odd to me, not sure what it is, it just seems cumbersome.

@tablatronix tablatronix added the Question User Question member to member support label Sep 10, 2017
@tzapu
Copy link
Owner

tzapu commented Sep 10, 2017

hi, i don t like it much either, but i think it was originally a pull request, and above my C skill anyway so I went with it.

open to any other option

@tablatronix
Copy link
Collaborator Author

Ill think about it, obviously we want to keep backward now that it is there, maybe we can add procedural wrappers to make it easier to use, so you do not have to keep track of objects and refs in user code.

Just add parameter(ID, object)
getparameter(ID,key), or value only etc.

@tzapu
Copy link
Owner

tzapu commented Sep 11, 2017

seems ok to me
breaking backwards compatibility on this should not be such a big thing, we could release it as 2.0
my line of thinking is that whoever got to the more advanced usage types, with params, would understand what needs fixing...

@liebman
Copy link
Contributor

liebman commented Sep 12, 2017

Just to add to the discussion, in one of my projects I needed to add more than 25 parameters and created a wrapper class to deal with much of the pain with registering them and what actions to take when they were changed via the form:

    ConfigParam tp_duration(wifi, "tp_duration", "Tick Pulse", config.tp_duration, 8, [](const char* result)
    {
        config.tp_duration = TimeUtils::parseSmallDuration(result);
        clk.writeTPDuration(config.tp_duration);
    });

@tablatronix
Copy link
Collaborator Author

Would it make more sense to register callbacks for param saves? Or a single callback that recieves an id and object?

@liebman
Copy link
Contributor

liebman commented Sep 12, 2017

I would prefer callbacks, one of my goals with the simple wrapper I created was to keep both the definition and action of the params close together. I would it was painful and error prone when the definition and registration of the params was separated from the actions. This made the code more readable and maintainable. If I needed to add/remove one or more params it was all in one place.

@liebman
Copy link
Contributor

liebman commented Sep 12, 2017

Oh, and lets absolutely manage the list of params without the user being required to specify the max-size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question User Question member to member support
Projects
None yet
Development

No branches or pull requests

3 participants