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
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}}
 
Clades:
* {{l/ver/clade|Aux|Register}}
* {{l/ver/clade|Aux|Manifest}}: did this end up being used?
* {{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}}

Revision as of 01:48, 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