Ferreteria/v0.6/sys/Registry

Registries different types and how they work

There are two primary types of "registry": class and object. Both of these are basically just arrays in which stored items follow a specific rule-set. In general, though, you have a list of things -- either classes or objects -- where the specific thing needed depends on context and identity.

The exact means of determining the context is perhaps the piece with the most variation in how it is implemented. It can be done by separate Registry classes or by using a "class slug" in a master-array.

The identity is simpler: the Registry (assuming the context is already specified) accepts a slug-string and returns the thing requested.

Pages

• class registry
• object registry

Notes

2025-10-16

I think the way this needs to work is that we should have two main clades for each registry-type:

1. Main registry
2. Per-class-slug roster:
   • Roster for class-names
   • Roster for objects

...except that on further thought, I don't really see the need for a central Registry to handle sub-registries. I think that may have come about for two reasons: (1) this functionality was first handled with a Globals singleton class, which then had to be refined to allow overrides, and (2) I needed some way to control the class-context for where the list was stored (e.g. if A has podlings B, C, and D, but we want A to be the "registrar" via a static member-array, how can we be sure each subclass isn't creating its own static array? I don't think it works that way, but there was enough uncertainty that it seemed wise to explicitly define where each podling-class registers itself).

...but I think if, instead of a registry-slug, we have a static registry object, it should be possible to ensure that it's not being replicated improperly.