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

Improve code reuse for Parameters in ParameterMap #2448

Closed
martyngigg opened this issue Sep 2, 2010 · 2 comments
Closed

Improve code reuse for Parameters in ParameterMap #2448

martyngigg opened this issue Sep 2, 2010 · 2 comments
Assignees
Labels
Extra Attention Testers and Gate keepers should pay extra attention as this affects core aspects. Framework Issues and pull requests related to components in the Framework Maintenance Unassigned issues to be addressed in the next maintenance period.
Milestone

Comments

@martyngigg
Copy link
Member

This issue was originally TRAC 1601

The ParameterMap currently stores Geometry::Parameter objects as its value type. On the surface it seems that the Parameter type offers very little over and above the more standard Property classes used by Algorithms.

We should look at whether the Geometry::Parameter classes can just be replaced and their functionality implemented with Property types as this would benefit on code sharing. We can then remove the separate, getIntParameter, getStringParameter etc methods on the component and simply have getParameter that returns an appropriate object, which can also be used in Python.

There is also a hole in the current mechanism whereby we can't do anything with the FitParameter class as it doesn't inherit from anything.


Keywords: Maintenance, Core

@martyngigg
Copy link
Member Author

@NickDraper (2010-12-16T09:49:15):
Bulk move of tickets to iteration 27, if your ticket is essential for Iteration 26 then move it back.


@NickDraper (2011-02-15T09:09:18):
Bulk move of tickets at the end of iteration 27


@NickDraper (2011-04-27T07:35:32):
Bulk move of tickets at the end of iteration 28


@NickDraper (2011-06-27T08:23:23):
Accepted and assigned tickets moved at iteration 29 code freeze


@NickDraper (2011-09-19T09:30:12):
Bulk move of tickets to iteration 31 at the iteration 30 code freeze


@NickDraper (2012-01-09T09:42:13):
Moved to iteration 33 at iteration 32 code freeze


@NickDraper (2012-04-30T14:10:45):
Moved at end of release 2.1


@NickDraper (2012-08-10T12:43:12):
Moved at the end of release 2.2


@NickDraper (2012-10-28T11:38:26):
Moved to milestone 2.4


@NickDraper (2013-04-29T09:49:29):
Moved to r2.6 at the end of r2.5


@martyngigg (2013-07-15T08:46:43):
Batch move to 2.7


@NickDraper (2014-02-14T11:04:54):
Bulk move to assigned at the introduction of the triage step

@martyngigg martyngigg added Framework Issues and pull requests related to components in the Framework Maintenance Unassigned issues to be addressed in the next maintenance period. Extra Attention Testers and Gate keepers should pay extra attention as this affects core aspects. labels Jun 3, 2015
@martyngigg martyngigg self-assigned this Jun 3, 2015
@martyngigg martyngigg added this to the Release 3.5 milestone Jun 3, 2015
@martyngigg
Copy link
Member Author

I think we are far enough down the road with the ParameterMap and its implementation that this is not worth the effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Extra Attention Testers and Gate keepers should pay extra attention as this affects core aspects. Framework Issues and pull requests related to components in the Framework Maintenance Unassigned issues to be addressed in the next maintenance period.
Projects
None yet
Development

No branches or pull requests

2 participants