Posted on Apr 9, 2023
I pushed to the public repositories the mbfl changes that overhaul the ‘semver’ module using oop; it is backwards incompatible. The basic usage template now looks like this:
mbfl_default_object_declare(SEMVER_SPEC) mbfl_default_object_declare(SEMVER_PARSER) mbfl_default_object_declare(PARSER_INPUT) declare -i START_INDEX=0 mbfl_semver_parser_input_make _(PARSER_INPUT) '1.2.3-alpha.1+x86-64' $START_INDEX mbfl_semver_parser_make_default _(SEMVER_PARSER) mbfl_semver_parse _(SEMVER_SPEC) _(SEMVER_PARSER) _(PARSER_INPUT) mbfl_declare_varref(MAJOR_NUMBER) mbfl_declare_varref(BUILD_METADATA) mbfl_semver_spec_major_number_var _(MAJOR_NUMBER) _(SEMVER_PARSER) mbfl_semver_spec_build_metadata_var _(BUILD_METADATA) _(SEMVER_PARSER) "$MAJOR_NUMBER" ⇒ 1 "$BUILD_METADATA" ⇒ x86-64
There is a lot to type, but I am sort of satisfied.
It is clear to me that the oop facilities need a way to specify the fact that a field is immutable and that its value must satisfy a predicate. Right now I make a field immutable by just deleting the field’s mutator function and for “typed” fields I redefine the mutator function to one that validates the new field value. Not good.
I do not know how to do it without introducing a full slot–descriptor object. I can imagine a metaclass instantiation function that parses its command line, mimicking r6rs syntactic records layer, something like:
mbfl_default_class_declare(color)
mbfl_default_class_define _(color) \
inherits: _(mbfl_default_object) \
name: 'color' \
fields: mutable: red color_red_var color_red_set \
immutable: green color_green_var \
mutable: blue color_blue_var color_blue_set
does it make sense? I dunno!