Typkatalog
Kurzfassung
- Der Typkatalog ist das Register der Named types, die Pipelogic standardmäßig ausliefert:
Image,AudioFrame,Tensor,BoundingBox,Polygonund das übrige Domänenvokabular. - Katalogtypen sind global: jeder Workspace sieht dasselbe Register. components referenzieren sie über ihren Namen in
component.yml; die Plattform validiert sie zur Übertragungszeit. - Für Ad-hoc-Formen, die keinen Katalogeintrag rechtfertigen, funktionieren anonyme Records auf der Leitung (
{x: Double, y: Double}) einwandfrei. Der Katalog ist das gemeinsame Vokabular, nicht das einzige. - Die Seite, die du gerade liest, ist das mentale Modell und die Kategorienkarte. Für das vollständige Record-Schema pro Typ, jede Variante, jede Wrapper-Klasse rufe die Referenz von der CLI ab:
ppl docs get type-api/catalog.
Warum ein gemeinsamer Katalog
Zwei components aus verschiedenen Teams einigen sich auf Image, weil das Register genau festlegt, was Image ist — ein Record mit width, height, einer Farbraum-Variante und einem Pixelpuffer. Der Produzent kodiert einmal, der Konsument dekodiert einmal, und der Typprüfer lehnt jede Leitung ab, bei der die beiden Enden uneinig sind. Ohne den gemeinsamen Katalog würde jedes Team seinen eigenen Image-Record erfinden, und die Verdrahtung würde nur durch Zufall funktionieren.
Kategorienkarte
Der Katalog gruppiert sich um die Datenformen, die echte KI-Produkte bewegen:
| Kategorie | Repräsentative Named types | Zweck |
|---|---|---|
| Bildgebung | Image, DepthImage | Frames in verschiedenen Bittiefen und Farbräumen. |
| Audio | AudioFrame | Float-Audio mit Abtastraten-Markierung. |
| Tensoren | Tensor, Embedding, PointMap3D, MetricDepthMap, DensityMap, OpticalFlow | Form-markierte N-D-Arrays; benannte Aliase tragen semantische Bedeutung. |
| Geometrie | Point, Rectangle, Ellipse, Polygon, BoundingBox, Landmark, Mask | 2-D-/3-D-Primitive, kombinierbar mit Bildgebungstypen. |
| Erkennung | DetectedClass, BoundingBox, Landmark | Inferenz-Ausgaben, auf die nachgelagerte Konsumenten aufbauen können. |
| Domäne | Audio-Untertitel, RAG-Records, Mesh / 3-D, Beobachtung / Metriken, … | Anwendungsspezifische Vokabulare, die die Plattform ausliefert. |
Jede Kategorie hat ihre eigene interne Schichtung — Image hat Farbraum-Varianten, Tensor hat zwei Skalar-dtypes, DepthImage hat drei Pixeltiefen-Varianten — aber ein component-Autor muss nur die Namen und die Formen kennen, die der Wrapper offenlegt.
Atomar vs. zusammengesetzt vs. benannt
- Atomar — eingebaute Skalartypen aus der Pipelang-Grammatik:
Int32,UInt32,Int64,UInt64,Float,Double,Bool,Char,String,Bytes. - Zusammengesetzt — aus allem über die Grammatik aufgebaut:
[T](Liste),(A, B)(Tupel),{x: A, y: B}(Record),A | B(Union),Name<T>(generisch). - Benannt — im Katalog registriert.
Image,AudioFrame,BoundingBox, … sind Records oder Unions mit einem stabilen Namen, den components referenzieren können.
Der Katalog ist die benannte Schicht. Die Grammatik, mit der du neue Typen aus Atomen zusammensetzt, ist separat dokumentiert: siehe /type-api/type-syntax.
Das richtige Vokabular wählen
Beim Schreiben einer component:
- Verwende einen atomaren Typ, wenn die Leitung einen Skalar trägt (
Doublefür einen Konfidenzschwellwert,Stringfür ein Label). - Verwende einen Named type, wenn ein offensichtlicher für die Domäne existiert (
Imagefür einen Frame,BoundingBoxfür eine Erkennung); der Rest des Ökosystems fügt sich automatisch ein. - Verwende einen zusammengesetzten Typ aus Named types, wenn der offensichtliche eine Liste, ein Tupel oder ein Optional ist (
[BoundingBox],(Image, String),Maybe<Tensor>). - Verwende einen anonymen Record (
{label: String, score: Double}), wenn die Form einmalig ist; taucht sie an drei Stellen auf, verdient sie einen Katalogeintrag.
Wo das hingehört
Named types sind die Lingua franca der Pipelogic-Backends. Jede component-Ausgabe, die du erzeugst, fließt durch einen dieser Namen; jede Eingabe, die du akzeptierst, ist auf dieselbe Weise benannt. Der Katalog ist der Grund, warum zwei Monate auseinander von verschiedenen Autoren geschriebene components ohne Übersetzungs-Kleber zusammenspielen.
Für die vollständige Referenz
Die Website behandelt das Modell und die Kategorienkarte. Für Record-Schemata pro Typ, die vollständigen Variantentabellen, JSON-Kodierungsdetails sowie die Python- und C++-Wrapper-APIs rufe die Referenz von der CLI ab:
ppl docs get type-api/catalogppl docs get type-api/type-syntaxVerwandt
- /type-api/types — das Typsystem als Plattformkonzept.
- /type-api/named-types — wann der Named-type-Katalog erweitert werden sollte vs. ein anonymer Record.
- /type-api/type-syntax — die Grammatik.
- /component-api/component-contract — wo du diese Typen deklarierst.