Skip to content

Inheritance, Composition and Mixins #9

@simontaurus

Description

@simontaurus

See also https://linkml.io/linkml/schemas/inheritance.html#mixin-classes-and-slots and https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem.
The diamond problem does not apply to JSON-SCHEMA since every schema included by allOf needs to be valid on the target document, meaning the following schema is invalid in any case:

allOf:
- title: B
  properties:
    x:
      title: xB
      type: integer
- title: C
  properties:
    x:
      title: xC
      type: string

This make sense also in case of beeing transferred to e.g. python dateclasses because otherwise casting from a more specific to a more general base class would not be possible.
The need to allow incompatible definitions applies actually only to annotations (like title, descriptions, etc) and class methods (out-of-scope for JSON-SCHEMA). In this case, the order of superclasses becomes important, e.g.

allOf:
- title: B
  properties:
    x:
      title: xB
      type: integer
      minimum: 1
- title: C
  properties:
    x:
      title: xC
      type: integer
      maximum: 10

will generate a web form with xB as label for x and a code generator will create

class Model(BaseModel):
    x: Optional[conint(ge=1, le=10)] = Field(None, title="xB")

Consistently,

class B:
    def echo(self):
        print("xB")
        
class C:
    def echo(self):
        print("xC")
        
class D(B,C):
    pass

D().echo()

will result in xB.

Other then the order with allOf there's no intrument in JSON-SCHEMA to indicate primary and secundary superschemas / classes. $ref could be regarded to have a different semantics as allOf: $ref but only a single value is allowed for $ref.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions