-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Comments
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 |
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) |
seems ok to me |
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:
|
Would it make more sense to register callbacks for param saves? Or a single callback that recieves an id and object? |
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. |
Oh, and lets absolutely manage the list of params without the user being required to specify the max-size. |
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.
The text was updated successfully, but these errors were encountered: