Proposal for parameter attribute inheritance changes in param v2 #113
Labels
API breaking
Affects the api in a non bug fixy way/consider version or name change
component: type/value stuff
system of parameter type/value checking, inheritnace, etc etc
type-feature
Feature request
Milestone
(draft proposal!)
Currently, Parameter attribute inheritance is a bit inconsistent (or
at least not well documented). By 'Parameter attribute', we mean
e.g. the
default
attribute (slot) of Parameter, or thebounds
slot of Number. The main problem in param v1 is that
None
wasoriginally used to mean 'not set', but eventually we started to use
None
as a valid value too.We're proposing to address these inheritance-related inconsistencies
in param v2. Below we list some proposed changes, and highlight
current inconsistencies using some example classes.
Changes:
NotImplemented
("notset"). Currently, some attributes default to None, while many
default to other things (e.g. 1.0 for Number).
a Parameter of the same name defined in the superclass of the owning
Parameterized. Currently, this inheritance may or may not happen
(see examples later).
above, there will be an exception (nothing can be left 'unset').
class level (it's up to the person using that Parameter to supply
such a default). Note that this means e.g. the List parameter can no
longer default to an empty list (at the List class level).
attributes other than
default
(i.e. for the meta parameters). Forinstance, the author of the List parameter class can say
instantiate=True
by default for List parameters; then, when a Listparameter is declared in a Parameterized class, if the class author
does not specify a value for
instantiate
, and the Parameterizedclass's superclass (if any) does not have a List (subclass) of the
same name with a value for
instantiate
specified, theninstantiate
will be True for that List parameter.to be the same type as/a subclass of the x parameter class in owning
parameterized's superclass. Currently we don't enforce this.
Some classes (slightly modified from current reality for brevity) for
examples...
For the classes above, considering first the 'a' parameter, I think
the following is currently how things end up after the parameterized
classes have been created:
Some notes:
clearer with fewer special cases. But maybe not: it's ok for a
subclass to have more restriction than its superclass, and None
might not be meaningful for B even though it's meaningful for A.
Now considering the 'b' parameter...
Notes:
not a subclass of List.
outside the bounds. (Default values be checked after bounds are
inherited).
The text was updated successfully, but these errors were encountered: