MiZe Part

• rel: MiZe Init System

current version by example (aka Config Oriented Programming)

// pure function, which just defines things.
fn part_smth() -> MireResult() {
	// define config options
	opt("my_opt")
		.fun(|| { // a function which calculates the value from other config values
			let a = get_config("some.other.option");
			return Ok(a + "hello there");
		})
	// this function should be rerun whenever some.other.option changes
	// and like Nix you should be able to specify a merge strategy or smth.
	
	method("my_method", "String -> ()", || {
		// does smth to internal state
	})
	// goal is also to have method calls tracked, and be correctly reversable in the state when a part is unloaded.

	// some code to run in a thread if the part is enabled
	// the thread should restart smth i uses get_config() on changes.
	thread("my_worker" || {
	})
	
	// smth which runs on every change of all get_config()'d values
	// should apply what is in the values to some OS state, eg write a config file.
	apply("my_repeatable_side_effect", || {
	})

	// simply set config to modfy behaviour of another part.
	set_config("some.other.part.some_opt")
}

some old thoughts

(mostly from 2025-11-10)

• the current architecture of the Compass Bot (as of this commit) is the simplest/easiest/less-mizeified way of using mize parts… just have a “struct” like data type for your App… which contains as attributes all parts of the App… the init-func of the App calls all init-funcs of all parts in the order of their dependence… also parts may depend on other parts (which in this simple case is just reflected by the order their init-funcs are called)

  • in such simple usage… the “what happens when one part changes it’s public api” is fully up to the developer… and also parts like this are usually fully in the same codebase anyway.

• there can be a ServerApp and a ClienApp… where some parts are shared and some are not…

• some general parts

  • the general “config” part… is a part which provides a way of using config options ala Victorinix Config System
    • and also helper function to use the all important “-o” command flag to override options
  • the general “mize” part (in any application) is a part which simply provides a MiZe Instance…
  • the general “js” part provides a way of executing JS in whatever app it is part of
  • general parts for all programming languages… (this is the mize way of inter lang programming)
  • …

• the js part also allows to write certain parts in js… this part written in js then get’s passed all it’s dependency parts as a js representation… meaning all public members and public methods are part of a generated js class… and access/call into the the other language…

  • we make tooling to analyze parts… and generate their representation in other languages… which uses the Mize Type System for data types used inside the parts…

• so libraries which are also coded like this (eg mize, vic)… export a struct… which can basically directly be used a such a part…

  • you can then when updating your project think in terms of all the parts versions…
  • and maybe parts can have their own versions in big projects…

• the more mizeifying you go…:

  • you eventually restrict all property/method signatures of a part to be of a mize type (or even an item)… meaning you can do all interactions of the parts through mize… and completely remotely
  • you eventually use Victorinix Init System… meaning a part no longer has a simple init func… but a definition of init steps which can be run in parallel to some degree… and MiZe Init-Caching System

• definition of a part: a set of public properties (which can be sub parts) and/or methods

• parts can have one generic part (like “audio”)… which then may have one ore multiple more specific implementations (like pulseaudio, jack, windiows-audio-system, browser-audio, pipewire-audio, macos-audio)… where the generic part has maybe some generic methods/properties… and in his Victorinix Options it says what “impl-parts” are available… where the user of the audio part then has to be able to work with one of those…

  • this brings us right to Mize OS Parts… which are also simply MiZe Parts… of the application MiZe OS

• how do we deal with multi threading?????????????????????????????