User should be DISCOURAGED from accessing the graph object
in drawing callbacks and encouraged to use the values from
the context instead, which are for many reasons more actual
and reliable than seemingly similar graph properties.
Which is why graph should be at least as hard to access as them,
which is why graph belongs into options/context, and not as
a self parameter. And since there can be no "self" parameter,
the last semblance of analogy to signals/callbacks is moot, and
the context parameter should be moved back to the last place,
where it belongs due to its low usefulness.
Things like step_width though, which are of direct immediate
use for 99.9% of callbacks, should be elevated to parameters,
EVEN if they were the same thing as graph properties.
And when merging context into options via __index metatable, one
should separately document the context first and link to its
documentation, instead of appending an ad-hoc list of its fields,
which can get obsolete.
Which is also incidentally another reason why the options table
should have fields starting with underscores - to not accidentally
shadow a newly introduced context field, however unlikely that is.
Properties, whose getters return a value different from
what the setter was last called with, are usually too much magic
and cognitive overload, than it's worth.
Returning a different "default value" on nil can hide issues and
make user blame the widget, in case they set the property to nil
as a result of their failed computation, which they thought to
produce a non-nil result, different from the "default value".
And as a developer, one has to constantly remember, which
properties and where should be accessed directly and where
through the magic getter, because it's suddenly not the same thing.
In short, anything that is accessed through [],
i.e. looks like data, should behave like plain data.
Otherwise it should be accessed through a function,
which it really is.
If one wants some defaults consistently applied
everywhere it should be done with a helper function,
that should be called everywhere, and not with a property
access, which is harder to find, EVEN IF the property is
magic and does the same thing. It should be then just
implemented by delegating to the helper function.
But most properties with defaults are used in the
graph widget code only once, so neither magic properties nor
helper functions are warranted.
If one still wants, that some properties never return
nil, then they should be populated in the constructor and
forbidden to be set to nil ever by a validating setter.
f3bd13da87