Ferreteria/v0.6/sys/Registry: Difference between revisions

From Woozle Writes Code
Jump to navigation Jump to search
(Created page with "{{fmt/title|Registries|different types and how they work}} There are two primary types of "registriy", '''class''' and '''object'''. Both of these are basically just arrays in which stored items follow a specific rule-set. ==Class Registry== * '''Purpose''': You have a set of classes (clade-family) for handling a situation, but the exact class to be used depends on circumstances (and may be extended by applications) -- so you need a list of alias-strings (class-slugs) wh...")
 
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{fmt/title|Registries|different types and how they work}}
{{fmt/title|Registries|different types and how they work}}
There are two primary types of "registriy", '''class''' and '''object'''. Both of these are basically just arrays in which stored items follow a specific rule-set.
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''.
==Class Registry==
* '''Purpose''': You have a set of classes (clade-family) for handling a situation, but the exact class to be used depends on circumstances (and may be extended by applications) -- so you need a list of alias-strings (class-slugs) where each corresponds to a particular context. Given a class-slug, the Registry looks up the corresponding class to use.


To be determined: do we use the multi-layer approach with these (if we use them at all), or is each class-registry just a separate object/instance?
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.
===structure===
Class registries are relatively simple: each entry has a string-value which is the name of an existing PHP class.
===use-cases===
As of 2025-10-15: I'm not sure if this concept is currently in use. There's a variant, {{l/ver/clade|Config|Classes}}, where the context is invoked through a function. I'm not sure if this is in use either, though that at least is easier to check ({{hashtag|TODO}}).


Clades:
The ''identity'' is simpler: the Registry (assuming the context is already specified) accepts a slug-string and returns the thing requested.
* {{l/ver/clade|Config|Classes}}
==Pages==
* {{l/ver/clade|Config\Roster|Classes}}
* {{l/sub|class}} registry
==Object Registry==
* {{l/sub|object}} registry
{{hashtag|TODO}}
==Notes==
==={{fmt/date|2025|10|16}}===
I think the way this needs to work is that we should have two main clades for each registry-type:
# Main registry
# Per-class-slug roster:
#* Roster for class-names
#* Roster for objects


Clades:
...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).
* {{l/ver/clade|Aux|Register}}
 
* {{l/ver/clade|Aux|Manifest}}: did this end up being used?
...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.
* {{l/ver/clade|Aux\StandardBase|Objectory}}
* {{l/ver/clade|Config\Roster\for|AnObject}}: trait/iface for adding Roster functionality to a clade
* {{l/ver/clade|Config\Roster|Objects}}

Latest revision as of 17:01, 16 October 2025

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

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.

Retrieved from "https://wooz.dev/mw/index.php?title=Ferreteria/v0.6/sys/Registry&oldid=7822"