right now in the docs i specify properties and methods as two distinct types of members that may be present in an nest_ or _affordance but I really should take this further. the reason for this is that some members are assumed to be "static" (my be set at init time, does not expect to be changed after initialization) and others are prepared to be "dynamic" (can be changed after initialization, i.e. in another action function, as long as it is followed by a call to refresh). here's a rough breakdown of how this might look:
property (dynamic)
static property (static)
child (static): nest_ or _affordance members, sorted by the order static property
method (dynamic)
builtins (static, readonly)
I think it's fine for now to treat as a documentation issue, but later on I work on some __index or proxy-based methodology to "protect" static properties from overwrites outside of the new() method.
right now in the docs i specify properties and methods as two distinct types of members that may be present in an
nest_or_affordancebut I really should take this further. the reason for this is that some members are assumed to be "static" (my be set at init time, does not expect to be changed after initialization) and others are prepared to be "dynamic" (can be changed after initialization, i.e. in another action function, as long as it is followed by a call torefresh). here's a rough breakdown of how this might look:nest_or_affordancemembers, sorted by theorderstatic propertyI think it's fine for now to treat as a documentation issue, but later on I work on some
__indexor proxy-based methodology to "protect" static properties from overwrites outside of thenew()method.