{ "model": { "rank": 2992, "code": "thing-q79872", "model_id": "vr.tr.object-oriented-programming", "name": "object-oriented programming", "purpose": "Enable an AI agent to recognise an object-oriented programming approach, assess how its objects preserve contracts and collaborate, and determine which implementation or design changes are justified.", "family": "Thing Registry", "category": "Activities and processes", "status": "research-draft", "kind": "thing", "plane": "ACT", "domain": "ACT.ACT", "industry": "", "version": "", "url": "/models/thing/q79872/", "tier": 2, "score": 93, "payload": { "layer": "wikidata", "aliases": [ "prototype-based programming", "object-oriented programming in PHP", "Python Programming/Classes", "actor-based programming", "class-based programming", "concurrent object-oriented programming" ], "aliasCount": 6, "merged": 6, "knownIn": 93, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q79872", "url": "https://www.wikidata.org/wiki/Q79872", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-07T14:10:53Z", "providers": [ "Codex", "Grok" ], "missingProviders": [], "pass": 2, "cost": { "grok": { "usd": 0.0107882, "turns": 1, "seconds": 146.3, "error": null }, "codex": { "seconds": 76.5, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.3\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a07c30-2fa2-7a92-8add-a8a647042a82\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: object-oriented programming\nRegistry id: vr.tr.object-oriented-programming\nPlane / domain: ACT / ACT.ACT\nRegistry definition: (none recorded)\nNames f" } } }, "metaModel": { "id": "THING-Q79872", "registryId": "vr.tr.object-oriented-programming", "name": "object-oriented programming", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "ACT.ACT" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q79872/", "model": { "registry_id": "vr.tr.object-oriented-programming", "name": "object-oriented programming", "purpose": "Enable an AI agent to recognise an object-oriented programming approach, assess how its objects preserve contracts and collaborate, and determine which implementation or design changes are justified.", "definition": "Object-oriented programming is a programming paradigm that structures a program as interacting objects, each locally retaining and protecting state and exposing behaviour through methods or messages, with classification (classes or prototypes) and late-bound polymorphic dispatch used to share and vary that behaviour.", "scope_statement": "This model owns object-oriented programming as a programming approach and its application in a bounded software context: how objects combine identity, state and behaviour, expose contracts, select implementations and collaborate under explicit language semantics.", "in_scope": [ "Evidence that a program organises behaviour around objects and their interactions", "Object identity, state ownership, encapsulation and invariants", "Class-based or prototype-based object construction and behaviour reuse", "Method lookup, dynamic dispatch, polymorphism and behavioural contracts", "Object collaboration, composition, inheritance and substitutability", "Assessment and modification of an object-oriented design within its implementation context" ], "out_of_scope": [ "Complete programming-language syntax, compiler implementation and language specification", "General software requirements, product capabilities and business-domain definitions", "Database schemas, persistence engines and object-relational mapping configuration", "Deployment architecture, infrastructure operation and service topology", "General project management, developer competency and team organisation", "Functional, procedural or logic programming except where needed to identify boundaries or mixed approaches" ], "distinguishing_features": [ "Determine whether objects receive operations through a defined interface and supply associated behaviour; records merely passed among free functions are insufficient evidence by themselves.", "Determine whether object boundaries organise responsibilities and state access in actual code; the presence of class declarations alone does not establish an object-oriented design.", "Identify whether operations can select behaviour through a receiver's class, prototype or other object mechanism; distinguish this from branches over externally interpreted type tags without assuming every object-oriented design requires dynamic dispatch.", "Determine whether classes act as object definitions, namespaces or data containers; distinguish object-oriented use from procedural code packaged inside classes.", "For an entity-component design, determine whether behaviour resides in collaborating objects or primarily in systems processing passive components; record mixed cases rather than classifying by terminology." ], "characteristics": [ { "name": "Assessment boundary", "kind": "category", "unit_or_values": "language capability | codebase | subsystem | library | design proposal", "why_it_matters": "Separates what a language permits from what a particular implementation actually does." }, { "name": "Object organisation mechanism", "kind": "category", "unit_or_values": "class-based | prototype-based | hybrid | other documented mechanism | unresolved", "why_it_matters": "Determines how objects obtain behaviour and which construction or extension operations are available." }, { "name": "Identity semantics", "kind": "category", "unit_or_values": "reference identity | value equality | both with explicit distinction | context-dependent | unresolved", "why_it_matters": "Controls whether replacement, copying and aliasing preserve observable behaviour." }, { "name": "State exposure", "kind": "category", "unit_or_values": "hidden behind operations | exposed read-only | directly mutable | mixed | unresolved", "why_it_matters": "Shows which callers can bypass invariant-preserving operations." }, { "name": "Dispatch mechanism", "kind": "category", "unit_or_values": "Record supported and used mechanisms, such as static binding, receiver-based dynamic dispatch, multiple dispatch or prototype delegation.", "why_it_matters": "Determines which implementation an operation invokes and how extensions affect callers." }, { "name": "Behavioural contract evidence", "kind": "state", "unit_or_values": "unspecified | documented | partially checked | checked within a stated boundary | known violation", "why_it_matters": "Distinguishes an assumed contract from one supported by review, tests or formal evidence." }, { "name": "Reuse and substitution relationships", "kind": "relation", "unit_or_values": "composition | delegation | implementation inheritance | declared subtyping | structural compatibility; identify endpoints and evidence", "why_it_matters": "Prevents code reuse from being mistaken for behavioural substitutability." }, { "name": "Inheritance depth", "kind": "measurement", "unit_or_values": "Maximum number of inheritance edges from a root to a assessed type, with treatment of multiple inheritance stated", "why_it_matters": "Indicates how far inherited behaviour may need to be traced; it is not a standalone quality score." }, { "name": "Mutable-state sharing", "kind": "relation", "unit_or_values": "Record which objects share access to mutable state and which operations may modify it.", "why_it_matters": "Reveals where local changes can affect other objects and where coordination is required." } ], "affordances": [ "Classify a bounded implementation's object-oriented mechanisms using code and language evidence.", "Trace an operation from its receiver through method lookup, dispatch and delegated calls.", "Identify exposed state, invariant violations and unsafe assumptions about object identity.", "Assess whether a proposed subtype preserves the behavioural expectations of its callers.", "Propose changes to responsibility allocation, interfaces, composition or inheritance and specify the evidence needed before applying them.", "Construct checks for object contracts, lifecycle transitions and polymorphic behaviour." ] }, "sources": [ { "id": "kay-1993-smalltalk", "title": "The Early History of Smalltalk", "url": "https://dl.acm.org/doi/10.1145/155360.155364", "what_it_supports": "Kay's specialist account of OOP as messaging, local retention and protection of state, and extreme late binding, against later class-and-inheritance reductions.", "url_status": "blocked" }, { "id": "wegner-1987-oopsla", "title": "Dimensions of Object-Based Language Design", "url": "https://dl.acm.org/doi/10.1145/38765.38823", "what_it_supports": "The still-used split between object-based languages (objects) and object-oriented languages (objects plus inheritance), and other design dimensions.", "url_status": "blocked" }, { "id": "armstrong-2006-cacm", "title": "The Quarks of Object-Oriented Development", "url": "https://dl.acm.org/doi/10.1145/1113034.1113040", "what_it_supports": "Empirical practitioner consensus that encapsulation, inheritance, and polymorphism are the properties people actually treat as definitional.", "url_status": "blocked" }, { "id": "chidamber-kemerer-1994", "title": "A Metrics Suite for Object Oriented Design", "url": "https://doi.org/10.1109/32.295895", "what_it_supports": "The CK quantities (WMC, DIT, NOC, CBO, RFC, LCOM) still used to measure OO designs.", "url_status": "live" }, { "id": "cardelli-wegner-1985", "title": "On Understanding Types, Data Abstraction, and Polymorphism", "url": "https://dl.acm.org/doi/10.1145/6041.6042", "what_it_supports": "How inclusion polymorphism and data abstraction underpin typed OOP, and how that differs from ADTs alone.", "url_status": "blocked" }, { "id": "omg-uml", "title": "Unified Modeling Language (UML) specification", "url": "https://www.omg.org/spec/UML/", "what_it_supports": "The dominant industrial notation for class, object, and related structure used to describe OO systems.", "url_status": "live" } ], "structure": { "bundles": [ { "id": "paradigm-and-object-mechanisms", "name": "Paradigm and object mechanisms", "description": "Establishes where object-oriented programming is being assessed and how objects are represented.", "rationale": "An agent must distinguish actual object-oriented organisation from language support, class syntax or terminology.", "layers": [ { "id": "application-boundary", "name": "Application boundary", "description": "Defines the unit of assessment and the evidence for its programming approach.", "findings": [ { "id": "object-oriented-organisation", "name": "Object-oriented organisation", "description": "Records how responsibilities and interactions are organised around objects within the selected boundary.", "questions": [ { "text": "Which codebase, subsystem or design proposal is assessed, and which responsibilities are assigned to objects?", "kind": "boundary", "id": "object-oriented-organisation-q01" }, { "text": "Which code examples or design records demonstrate object-centred behaviour rather than classes used only as namespaces or records?", "kind": "provenance", "id": "object-oriented-organisation-q02" } ] } ] }, { "id": "object-definition-mechanisms", "name": "Object definition mechanisms", "description": "Identifies how instances obtain state and behaviour.", "findings": [ { "id": "classes-prototypes-and-instance-structure", "name": "Classes, prototypes and instance structure", "description": "Records the mechanisms used to define, instantiate and alter objects without treating classes as mandatory.", "questions": [ { "text": "Do objects obtain behaviour from classes, prototypes, per-instance members or another documented mechanism?", "kind": "definition", "id": "classes-prototypes-and-instance-structure-q01" }, { "text": "Can an object's members or behaviour providers change after creation, and what language or runtime evidence establishes this?", "kind": "provenance", "id": "classes-prototypes-and-instance-structure-q02" } ] } ] } ] }, { "id": "identity-state-and-encapsulation", "name": "Identity, state and encapsulation", "description": "Captures what makes an object the same object and how its state remains valid.", "rationale": "Safe object manipulation depends on distinguishing identity from equality and knowing who can alter state.", "layers": [ { "id": "identity-and-aliasing", "name": "Identity and aliasing", "description": "Examines equality, copying and shared references.", "findings": [ { "id": "identity-equality-and-copy-contracts", "name": "Identity, equality and copy contracts", "description": "Records when references denote the same object and when distinct objects count as equal.", "questions": [ { "text": "How are object identity and value equality distinguished, including any equality and hashing contract?", "kind": "definition", "id": "identity-equality-and-copy-contracts-q01" }, { "text": "When an object is copied or replaced, which identities and references remain shared, and which caller observations must remain equivalent?", "kind": "action", "id": "identity-equality-and-copy-contracts-q02" } ] } ] }, { "id": "state-access-and-invariants", "name": "State access and invariants", "description": "Identifies protected conditions and paths that can bypass their enforcement.", "findings": [ { "id": "invariant-enforcement-boundary", "name": "Invariant enforcement boundary", "description": "Records valid object states, permitted mutation paths and the limits of encapsulation.", "questions": [ { "text": "Which conditions must hold at observable operation boundaries, and which constructors or methods establish and preserve them?", "kind": "definition", "id": "invariant-enforcement-boundary-q01" }, { "text": "Can callers bypass those methods through public fields, mutable values returned by accessors, aliases or reflective access?", "kind": "boundary", "id": "invariant-enforcement-boundary-q02" } ] } ] } ] }, { "id": "interfaces-dispatch-and-substitution", "name": "Interfaces, dispatch and substitution", "description": "Connects callable object contracts with implementation selection and replacement.", "rationale": "An agent must know both which behaviour executes and whether alternative implementations satisfy caller expectations.", "layers": [ { "id": "operation-resolution", "name": "Operation resolution", "description": "Captures how a requested operation resolves to executable behaviour.", "findings": [ { "id": "method-lookup-and-dispatch", "name": "Method lookup and dispatch", "description": "Records binding, overriding and lookup rules used by the assessed implementation.", "questions": [ { "text": "For a representative operation, which receiver, declared types, runtime types or prototype links determine the selected implementation?", "kind": "definition", "id": "method-lookup-and-dispatch-q01" }, { "text": "Which language rules and code evidence distinguish overloading, overriding, member hiding and delegation where they occur?", "kind": "provenance", "id": "method-lookup-and-dispatch-q02" } ] } ] }, { "id": "behavioural-compatibility", "name": "Behavioural compatibility", "description": "Assesses polymorphic replacement against observable obligations.", "findings": [ { "id": "substitution-obligations", "name": "Substitution obligations", "description": "Records preconditions, outcomes, failures and state effects that implementations must preserve.", "questions": [ { "text": "What inputs, results, exceptions and state changes may callers rely on through the shared interface?", "kind": "definition", "id": "substitution-obligations-q01" }, { "text": "What evidence shows that a proposed replacement accepts the required inputs and preserves those guarantees?", "kind": "action", "id": "substitution-obligations-q02" } ] } ] } ] }, { "id": "responsibilities-and-object-collaboration", "name": "Responsibilities and object collaboration", "description": "Describes how objects divide work and combine behaviour.", "rationale": "Object boundaries determine where changes belong and how their effects propagate through collaborators.", "layers": [ { "id": "responsibility-allocation", "name": "Responsibility allocation", "description": "Locates decisions, state and operations across collaborating objects.", "findings": [ { "id": "collaboration-and-knowledge-boundaries", "name": "Collaboration and knowledge boundaries", "description": "Records which objects perform a task and how much each knows about others' internals.", "questions": [ { "text": "For a representative task, which object owns each decision and which collaborators does it invoke?", "kind": "definition", "id": "collaboration-and-knowledge-boundaries-q01" }, { "text": "Which interactions depend on collaborators' internal representation or long navigation chains, and what changes would those dependencies propagate?", "kind": "boundary", "id": "collaboration-and-knowledge-boundaries-q02" } ] } ] }, { "id": "reuse-and-extension", "name": "Reuse and extension", "description": "Separates behaviour sharing from interface compatibility.", "findings": [ { "id": "inheritance-composition-and-delegation", "name": "Inheritance, composition and delegation", "description": "Records the intent and consequences of each mechanism used to reuse or extend behaviour.", "questions": [ { "text": "Which relationships provide implementation reuse, which promise substitution, and which forward work to contained or referenced objects?", "kind": "definition", "id": "inheritance-composition-and-delegation-q01" }, { "text": "For a proposed extension, what caller contracts, override dependencies and ownership assumptions determine whether inheritance, composition or delegation is appropriate?", "kind": "action", "id": "inheritance-composition-and-delegation-q02" } ] } ] } ] }, { "id": "object-lifecycle-and-change-evidence", "name": "Object lifecycle and change evidence", "description": "Records when objects are usable and what evidence permits changes to their behaviour or structure.", "rationale": "Correct method definitions alone do not establish valid construction, safe retirement or preservation of behaviour during change.", "layers": [ { "id": "construction-and-retirement", "name": "Construction and retirement", "description": "Captures object readiness, valid transitions and responsibility for resources.", "findings": [ { "id": "lifecycle-validity", "name": "Lifecycle validity", "description": "Records how objects become valid, which operations are legal in each state and how obligations end.", "questions": [ { "text": "When does an object become valid for use, and can partially initialised state escape through callbacks, registration or overridable constructor calls?", "kind": "boundary", "id": "lifecycle-validity-q01" }, { "text": "Which operations are permitted after each lifecycle transition, and who must release any resources the object owns?", "kind": "action", "id": "lifecycle-validity-q02" } ] } ] }, { "id": "behaviour-preserving-change", "name": "Behaviour-preserving change", "description": "Defines the observations and checks needed to assess object-oriented refactoring.", "findings": [ { "id": "refactoring-evidence", "name": "Refactoring evidence", "description": "Records whether a proposed structural change preserves required contracts, identity effects and interactions.", "questions": [ { "text": "Which observable results, state transitions, identity relationships and collaborator effects must a proposed refactoring preserve?", "kind": "boundary", "id": "refactoring-evidence-q01" }, { "text": "Which contract checks and representative interaction tests support the change, and which affected behaviours remain unchecked?", "kind": "action", "id": "refactoring-evidence-q02" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Class-based OOP (objects instantiated from classes; Simula, Smalltalk, Java, C++, C#, Python)", "Prototype-based OOP (objects cloned and extended from other objects; Self, JavaScript, Lua)", "Message-passing OOP (computation as sending messages to a receiver; Smalltalk, Objective-C, some actor-flavoured designs)", "Statically typed, nominal class OOP with compile-time checking (C++, Java, C#, Eiffel, Ada tagged types)", "Object-based style: encapsulation and identity without inheritance (Wegner's distinction; some early Visual Basic, modules-as-objects)", "Multiple-inheritance OOP versus single inheritance plus interfaces or protocols (C++/Eiffel/Python versus Java/C#/Objective-C)", "Trait-, mixin-, or composition-based OOP (Scala traits, Ruby mixins, Rust-adjacent trait objects in multi-paradigm use)", "Hybrid / multi-paradigm OOP, where objects coexist with procedures, functions, or generic programming in one language" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of object-oriented programming this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "scheme": "Wikidata", "value_or_pattern": "Q79872", "note": "Item 'object-oriented programming'." }, { "scheme": "Library of Congress Subject Headings", "value_or_pattern": "Object-oriented programming (Computer science)", "note": "Standard bibliographic heading; related headings cover object-oriented methods and languages." }, { "scheme": "Wikipedia / Wikimedia sitelink", "value_or_pattern": "Object-oriented_programming", "note": "English article title; other language editions use local equivalents (e.g. Programmation orientée objet)." }, { "scheme": "ACM Computing Classification System (2012)", "value_or_pattern": "Software and its engineering ~ Software notations and tools ~ General programming languages ~ Language types ~ Object oriented languages", "note": "CCS concept path rather than a short numeric code; used to index the literature." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of object-oriented programming this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "ISO/IEC 14882, Programming languages - C++ (ISO/IEC JTC 1/SC 22) - the principal international standard for a widely used class-based OO language.", "ISO/IEC 8652, Ada (ISO/IEC JTC 1/SC 22) - tagged types, dispatching, and related OO features in Ada.", "ISO/IEC 19505 (UML) / OMG Unified Modeling Language (Object Management Group, also published via ISO/IEC JTC 1) - modelling standard for OO structure and behaviour.", "ECMA-262, ECMAScript Language Specification (Ecma International; also ISO/IEC 16262) - prototype-based objects and, later, class syntax on top of prototypes.", "ANSI INCITS 319-1998 (R2007), Programming Language Smalltalk (INCITS/ANSI) - standardised Smalltalk, the canonical message-passing OO language.", "Java Language Specification (Oracle / Java Community Process) - de facto standard for mainstream statically typed class-based OOP; not an ISO language standard.", "OMG CORBA and related IDL (Object Management Group) - historically governed distributed objects, now largely legacy." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of object-oriented programming this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Enterprise information systems and application servers written in Java or C#, organised as classes, interfaces, and dependency-injected services.", "Desktop and mobile GUI toolkits (AppKit/UIKit, Android views, Qt, WPF, Swing/JavaFX) in which widgets are objects in an inheritance tree receiving events.", "Game engines and real-time simulations (Unity C# behaviours, Unreal C++ actors/UObject) where entities are objects with components or inheritance.", "Introductory computer-science courses that teach classes, objects, inheritance, and polymorphism as the first structuring method (often in Java or Python).", "CAD, compilers, and systems software in C++, using classes for ASTs, scene graphs, and resource owners.", "Web front ends in JavaScript/TypeScript, mixing prototypes, ES classes, and module objects.", "Analysis and design artefacts: UML class diagrams, CRC cards, domain models in DDD-style projects." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of object-oriented programming this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "quantity": "Depth of Inheritance Tree (DIT)", "typical_range": "1-4 in application classes; frameworks sometimes 5-8; deeper trees are treated as a smell", "unit": "inheritance levels" }, { "quantity": "Weighted Methods per Class (WMC) / method count", "typical_range": "a focused class often ~5-20 methods; much higher values flag god classes", "unit": "methods (sometimes complexity-weighted)" }, { "quantity": "Coupling Between Objects (CBO)", "typical_range": "commonly kept below about 5-9 coupled types in CK-threshold practice; large services exceed this", "unit": "distinct coupled classes" }, { "quantity": "Number of Children (NOC)", "typical_range": "0-3 for most application classes; base types in libraries may have tens to hundreds", "unit": "immediate subclasses" }, { "quantity": "Lack of Cohesion of Methods (LCOM, variant-dependent)", "typical_range": "near 0 for cohesive classes; high values (scale 0-1 or count-based) indicate split responsibilities", "unit": "index or pair-count, depending on LCOM variant" }, { "quantity": "Runtime object allocations", "typical_range": "from near-zero in stack-heavy C++ to millions per second in managed GUIs and servers", "unit": "allocations per second (or bytes allocated per second)" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of object-oriented programming this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Fragile base class: a change in a superclass silently breaks subclasses that depended on undocumented behaviour.", "Diamond problem and repeated inheritance: ambiguous or duplicated state/behaviour under multiple inheritance.", "God object / blob class: one type accumulates unrelated responsibilities, defeating encapsulation.", "Yo-yo problem: understanding a method requires bouncing up and down a deep inheritance chain.", "Inheritance used for code reuse instead of subtype relation, producing incorrect substitutability (Liskov violations).", "Object-relational impedance mismatch: graphs of objects map poorly onto relational tables, causing lazy-load, identity, and transaction bugs.", "Aliasing and hidden mutable shared state: two references mutate the same object, causing race conditions or surprising side effects.", "Anemic domain model: classes hold data but no behaviour, leaving the design as procedural code over structs.", "Virtual dispatch, heap allocation, and pointer chasing: cache-unfriendly layouts and unpredictable latency (the data-oriented critique).", "Over-abstraction and pattern soup: excessive interfaces and indirection that hide the actual control flow." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of object-oriented programming this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-regional-variation", "name": "Regional variation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "The paradigm originated in Norway (Simula 67, Nygaard/Dahl) and was reformulated in the US (Smalltalk at Xerox PARC; C++ at Bell Labs); teaching lineages still track those centres.", "In much European software-engineering usage, 'object orientation' names a whole method (OOA/OOD plus OOP, often with UML); US industry talk more often means the programming style in a given language.", "Eiffel/Meyer Design-by-Contract culture remains stronger in parts of Europe than in US enterprise Java/C# shops.", "Prototype-based practice is concentrated in JavaScript web culture; class-based static OOP dominates large organisations in North America, Europe, and East Asia.", "Introductory teaching has shifted in many English-speaking universities from Java-first OOP to Python, where OOP is optional and mixed with procedural style.", "Local names: German objektorientierte Programmierung, French programmation orientée objet, Russian объектно-ориентированное программирование; the English initialism OOP is widely borrowed." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of object-oriented programming this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "name": "Procedural programming", "difference": "Procedural code organises work as procedures operating on separate data; OOP binds data and operations to the same object identity and typically dispatches on the receiver." }, { "name": "Abstract data type (ADT)", "difference": "An ADT hides representation behind a type's operations but need not have object identity, inheritance, or late-bound messages; OOP objects are runtime identities that may be aliased and subclassed." }, { "name": "Functional programming", "difference": "FP centres on immutable values and function application without object identity as the main structuring device; OOP centres on encapsulated (often mutable) objects and polymorphic messages." }, { "name": "Modular programming", "difference": "Modules group declarations and control visibility at compile-time package granularity; objects are runtime instances with identity that can be created, aliased, and passed around." }, { "name": "Actor model", "difference": "Actors isolate state and communicate only by asynchronous messages, usually with concurrency in mind; ordinary OOP objects typically share a process and may be invoked synchronously, allowing aliasing." }, { "name": "Component-based software", "difference": "Components are independently deployable units wired through explicit provided/required interfaces; objects are language-level instances and need not be deployment or composition units." }, { "name": "Data-oriented design", "difference": "Data-oriented design lays out arrays of homogeneous data and transforms them for locality and throughput; OOP lays out heterogeneous objects with behaviour, often at the cost of that locality." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of object-oriented programming this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Which existing Vercy world models already own programming paradigms, object contracts or software design, and should this registry entry link to one of them?", "What operational recognition threshold should Vercy use for object-oriented programming in mixed codebases, especially where objects lack dynamic dispatch or contain little behaviour?", "Should the primary assessment unit be the programming approach itself or a bounded application of it, and how should those levels relate?", "Which language-specific extensions are needed for multiple dispatch, traits, mixins, prototype mutation and metaprogramming?", "When should concurrency, persistence identity and distributed object lifecycles extend this model rather than remain in neighbouring models?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 18, "questions": 28 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "abstract concept", "method": "Written from the archetype playbook - what this kind of thing needs beyond identity and provenance - and from the structure that recurred across 6,333 models already researched by two engines. Applied to this entry by rule. No source was read for this thing and no claim here is researched. This entry carries no facets of its own, so they were inferred from its domain - a guess about a whole domain applied to one thing.", "facetsInferred": true, "nextPass": "A researcher replaces this draft with a sourced specification. Treat every sentence below as a proposal to argue with.", "purpose": "Give an agent a durable, checkable way to recognise a object-oriented programming, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise an object-oriented programming approach, assess how its objects preserve contracts and collaborate, and determine which implementation or design changes are justified.", "characteristics": { "substance": "activity", "origin": "conceptual", "agency": "inert" }, "whatYouCanDoWithIt": [ "observed and measured" ], "distinguishingFeatures": [ "Names folded into this entry, which a task may need to split apart again: prototype-based programming, object-oriented programming in PHP, Python Programming/Classes, actor-based programming, class-based programming, concurrent object-oriented programming.", "6 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 93 Wikipedia languages, which is a measure of how widely the thing is known, not of how important it is." ], "openQuestionsForResearch": [ "Which of the bundles below does a real task actually need, and which are ceremony?", "What does this thing have that the facets do not capture at all?", "Which neighbouring kind is most often confused with a object-oriented programming, and on what evidence are they told apart?" ], "whatItIsMadeOf": "something that happens over time", "physicalCharacter": [ "Does nothing on its own; everything it does, something else did to it.", "These come from the domain this entry sits in rather than from the entry itself, so treat them as a first guess about the whole domain applied to one thing." ], "whatCanBeDoneWithIt": [ "observe it, measure it, record its state" ], "howItIsRecognised": [ "Nothing to see. What is recognised is an instance of it, and which instances count is exactly what is argued about." ], "relatedModels": [ { "relation": "covers", "note": "Finer kinds folded into this entry because telling them apart needs a task that asks for it. Each is a model waiting to be split out when one does.", "targets": [ "prototype-based programming", "object-oriented programming in PHP", "Python Programming/Classes", "actor-based programming", "class-based programming", "concurrent object-oriented programming" ] } ], "standing": "Described in 93 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 6 finer distinctions are held inside this entry as names rather than as separate models.", "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Identity, naming and classification", "description": "How an agent tells one object-oriented programming from another, and a object-oriented programming from things that resemble it.", "rationale": "Recognition comes before every other claim. Without stable identity nothing else in the model can be trusted to be about the same thing twice.", "layers": [ { "id": "naming-and-identifiers", "name": "Names and identifiers", "description": "The names this thing goes by and the identifiers that survive translation and time.", "findings": [ { "id": "preferred-name-and-aliases", "name": "Preferred name, aliases and local names", "description": "Which name to use, which names mean the same thing, and which merely sound similar.", "questions": [ { "id": "preferred-name-and-aliases-q01", "text": "What identifies and describes the name of a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "preferred-name-and-aliases-q02", "text": "Who or what asserted this about the name of a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "preferred-name-and-aliases-q03", "text": "What may an agent decide or do once the name of a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "stable-identifiers", "name": "Stable identifiers and external keys", "description": "Identifiers that keep pointing at this kind of thing across systems and languages.", "questions": [ { "id": "stable-identifiers-q01", "text": "What identifies and describes an identifier for a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stable-identifiers-q02", "text": "Who or what asserted this about an identifier for a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stable-identifiers-q03", "text": "What may an agent decide or do once an identifier for a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "classification-and-granularity", "name": "Classification and granularity", "description": "Where a object-oriented programming sits among kinds, and how finely a task needs to cut it.", "findings": [ { "id": "kind-and-parents", "name": "Kind, parents and neighbouring kinds", "description": "The classes this thing belongs to and the ones it is next to.", "questions": [ { "id": "kind-and-parents-q01", "text": "What identifies and describes the kind of a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "kind-and-parents-q02", "text": "Who or what asserted this about the kind of a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "kind-and-parents-q03", "text": "What may an agent decide or do once the kind of a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "distinguishing-features", "name": "Distinguishing features", "description": "What separates a object-oriented programming from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "distinguishing-features-q02", "text": "Who or what asserted this about what distinguishes a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "distinguishing-features-q03", "text": "What may an agent decide or do once what distinguishes a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "state-and-lifecycle", "name": "State and lifecycle", "description": "The states a object-oriented programming passes through and the events that move it between them.", "rationale": "Most decisions about a thing depend on what state it is in now, which is a claim with a time on it, not a property.", "layers": [ { "id": "lifecycle-stages", "name": "Lifecycle stages", "description": "From coming into existence to ceasing to be one of these.", "findings": [ { "id": "stages-and-transitions", "name": "Stages and transitions", "description": "The stages worth naming and what moves a object-oriented programming between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stages-and-transitions-q02", "text": "Who or what asserted this about the lifecycle of a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stages-and-transitions-q03", "text": "What may an agent decide or do once the lifecycle of a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "observations-and-status", "name": "Observations and current status", "description": "What is observed about a object-oriented programming, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a object-oriented programming is recorded so that it can be superseded rather than overwritten.", "questions": [ { "id": "observation-record-q01", "text": "What identifies and describes an observation of a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "observation-record-q02", "text": "Who or what asserted this about an observation of a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "observation-record-q03", "text": "What may an agent decide or do once an observation of a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "process-and-outcome", "name": "Process, inputs and outcome", "description": "How a object-oriented programming proceeds, what it needs and what it leaves behind.", "rationale": "An activity is known by its steps and its results, and both have to be recordable while it is still running.", "layers": [ { "id": "steps-and-sequence", "name": "Steps and sequence", "description": "The steps of a object-oriented programming, their order and what may run in parallel.", "findings": [ { "id": "steps-and-preconditions", "name": "Steps, preconditions and completion", "description": "What has to be true before each step of a object-oriented programming and what marks it done.", "questions": [ { "id": "steps-and-preconditions-q01", "text": "What identifies and describes a step of a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "steps-and-preconditions-q02", "text": "Who or what asserted this about a step of a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "steps-and-preconditions-q03", "text": "What may an agent decide or do once a step of a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "inputs-and-results", "name": "Inputs, resources and results", "description": "What a object-oriented programming consumes and what it produces.", "findings": [ { "id": "inputs-and-outputs", "name": "Inputs, outputs and side effects", "description": "The resources a object-oriented programming takes and the results it leaves, wanted or not.", "questions": [ { "id": "inputs-and-outputs-q01", "text": "What identifies and describes the inputs and results of a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "inputs-and-outputs-q02", "text": "Who or what asserted this about the inputs and results of a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "inputs-and-outputs-q03", "text": "What may an agent decide or do once the inputs and results of a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "definitions-in-contest", "name": "Definitions and who holds them", "description": "What object-oriented programming is taken to mean, and by whom.", "rationale": "When a field disagrees about a concept, the disagreement is the content. A model that picks one definition silently destroys the information.", "layers": [ { "id": "competing-definitions", "name": "Competing definitions", "description": "The main readings and the traditions behind them.", "findings": [ { "id": "definition-map", "name": "Definitions and their holders", "description": "Each definition with the school or body that holds it.", "questions": [ { "id": "definition-map-q01", "text": "Which definitions of object-oriented programming are in use, and which tradition or body holds each?", "kind": "definition" }, { "id": "definition-map-q02", "text": "What turns on the difference between them in practice?", "kind": "boundary" } ] } ] }, { "id": "operationalisation", "name": "Operationalisation", "description": "How it is measured or applied when it has to be.", "findings": [ { "id": "operational-record", "name": "Measures and proxies", "description": "Instruments and indicators used to stand in for it.", "questions": [ { "id": "operational-record-q01", "text": "How is object-oriented programming operationalised or measured in practice, and by what instrument?", "kind": "measurement" }, { "id": "operational-record-q02", "text": "What does that operationalisation leave out, and when does that matter?", "kind": "boundary" } ] } ] } ] }, { "id": "instances-and-use", "name": "Instances, use and consequence", "description": "What counts as an instance of object-oriented programming and what follows from calling something that.", "rationale": "Applying a concept is an act with consequences, so a model must say what the label licenses and what it does not.", "layers": [ { "id": "instances", "name": "What counts as an instance", "description": "Clear cases, borderline cases and non-cases.", "findings": [ { "id": "instance-tests", "name": "Tests for an instance", "description": "What would settle whether something falls under it.", "questions": [ { "id": "instance-tests-q01", "text": "What would settle whether something is an instance of object-oriented programming?", "kind": "boundary" }, { "id": "instance-tests-q02", "text": "Which borderline cases are argued about, and on what grounds?", "kind": "definition" } ] } ] }, { "id": "consequence", "name": "Consequence of application", "description": "Rights, duties or decisions that follow from the label.", "findings": [ { "id": "consequence-record", "name": "What the label licenses", "description": "What an agent may do once something is classified this way.", "questions": [ { "id": "consequence-record-q01", "text": "What follows practically once something is treated as object-oriented programming?", "kind": "action" }, { "id": "consequence-record-q02", "text": "What must an agent not infer from the label alone?", "kind": "action" } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a object-oriented programming came from and when it held.", "rationale": "A claim without a source and a time cannot be superseded, only overwritten, and an agent that overwrites loses the ability to explain itself.", "layers": [ { "id": "source-and-authority", "name": "Source and authority", "description": "Who said it, on what evidence, and how strongly.", "findings": [ { "id": "claim-provenance", "name": "Claim provenance and confidence", "description": "The authority behind each claim about a object-oriented programming and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "claim-provenance-q02", "text": "Who or what asserted this about a claim about a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "claim-provenance-q03", "text": "What may an agent decide or do once a claim about a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "time-and-versions", "name": "Time, versions and supersession", "description": "When a claim was true, when it was learnt, and what replaced it.", "findings": [ { "id": "validity-and-supersession", "name": "Validity period and supersession", "description": "How an old claim about a object-oriented programming is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a object-oriented programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "validity-and-supersession-q02", "text": "Who or what asserted this about the validity of a claim about a object-oriented programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "validity-and-supersession-q03", "text": "What may an agent decide or do once the validity of a claim about a object-oriented programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 6, "layers": 12, "findings": 14, "questions": 38 } } } }