Extends

Overview

Extends is ParamML's mechanism for reusing and building upon existing objects. It implements inheritance - a core concept from Object-Oriented Programming (OOP).

What you'll learn:

Basic Extends syntax
Single and multiple inheritance
Versioning library components
Override mechanism (critical rules!)
When to use Scoped="1"
Top-level vs Group-level extends
Type inheritance and compatibility
Common patterns and best practices

What is Extends?

The Extends attribute allows an object to inherit all parameters and sub-objects from one or more parent objects.

Key concepts:

A child receives all parameters and sub-objects from its parent(s)
Children can add new parameters and objects
Children can override inherited content using Override="1"
Extends is transitive (grandparent → parent → child)
Extends supports multiple inheritance (multiple parents)

Inheritance: The Underlying Concept

Inheritance means deriving a new object from an existing one. Think of it like:

Parent = Base template
Child = Specialized version with everything from parent + additions/changes

Conceptual Example

Person
├── Employee
│   └── Engineer
└── Student

An Engineer includes all attributes from:

Person (age, name)
Employee (working_hours, income)
Engineer (field, position)

Basic Syntax

Use the Extends attribute to inherit from another object:

<O N="Child" T="Project" Extends="Parent">
    <!-- Child inherits everything from Parent -->
</O>

Critical rule: Every object must have a T (Type) attribute, even when using Extends:

<!-- ✅ Correct - has T attribute -->
<O N="Child" T="Project" Extends="Parent">

<!-- ❌ Wrong - missing T -->
<O N="Child" Extends="Parent">

Single Inheritance

Example: Person → Employee → Engineer

Base: Person

<O N="Person" T="Project">
    <P N="age" V="21" Role="Input" />
    <P N="name" V="John" T="Text" Role="Input" />
</O>

Child: Employee extends Person

<O N="Employee" T="Project" Extends="Person">
    <!-- Inherits: age, name -->
    
    <!-- Adds new parameters -->
    <P N="working_hours" V="8" Role="Input" />
    <P N="experience" V="10" Role="Input" />
    <P N="income" V="25000" Role="Input" />
</O>

Grandchild: Engineer extends Employee

<O N="Engineer" T="Project" Extends="Employee">
    <!-- Inherits: age, name, working_hours, experience, income -->
    
    <!-- Adds new parameters -->
    <P N="field" V="thermodynamics" T="Text" Role="Input" />
    <P N="position" V="project manager" T="Text" Role="Input" />
</O>

Result:

Person has: age, name
Employee has: age, name, working_hours, experience, income
Engineer has: age, name, working_hours, experience, income, field, position

Multiple Inheritance

Use array syntax to extend from multiple parent objects:

<O N="Child" T="Project" Extends="[Parent1, Parent2, Parent3]">
    <!-- Child inherits from all three parents -->
</O>

Example: Multiple Base Classes

<O N="GeometricProperties" T="Project">
    <P N="area" V="1000" />
    <P N="volume" V="5000" />
</O>

<O N="MaterialProperties" T="Project">
    <P N="density" V="2400" />
    <P N="strength" V="30" />
</O>

<O N="LoadProperties" T="Project">
    <P N="dead_load" V="100" />
    <P N="live_load" V="50" />
</O>

<!-- Child inherits from all three -->
<O N="StructuralElement" T="Project" Extends="[GeometricProperties, MaterialProperties, LoadProperties]">
    <!-- Has: area, volume, density, strength, dead_load, live_load -->
    
    <P N="utilization" V="(dead_load + live_load) / (area * strength)" />
</O>

Best Practice: Avoid duplicate parameter names across parent objects to prevent ambiguity.

Versioning

Library components can have versions. Use ::v# syntax:

<O N="Child" T="Project" Extends="ComponentName::v3">
    <!-- Extends specific version -->
</O>

Version Syntax

<!-- Specific version -->
<O N="MyColumn" T="Project" Extends="Column::v5" />

<!-- Latest version (no version specified) -->
<O N="MyColumn" T="Project" Extends="Column" />

<!-- Multiple inheritance with mixed versioning -->
<O N="MyComponent" T="Project" Extends="[Base::v3, Helper, Calculator::v5, Utilities::v2]" />

Rules:

✅ Versioning applies only to library components
✅ No version = latest version
✅ Can mix versioned and non-versioned in array
❌ Cannot version local objects (in same file)

Example

<O N="MyColumn" T="Project" Extends="[OBPBase::v5, OBPHelper::v3]">
    <!-- Extends specific versions of library components -->
</O>

Override="1"

Override="1" is used to replace content inherited from parent.

Critical Rules

Override is an object attribute - can only be applied to objects, not parameters
Two ways to override:
- A) Override at Extends level (selective - only specified parameters)
- B) Override named object in parent (complete replacement - all parameters)

Override at Extends Level (Selective Override)

When you use Override="1" at the Extends level, you only override the parameters you define. Other parameters are inherited as-is.

Syntax

<O T="Group" Extends="Parent" Override="1">
    <P N="param_to_change" V="new_value" />
    <!-- Other parameters inherited from Parent -->
</O>

Example

<O N="Parent" T="Project">
    <P N="width" V="100" />
    <P N="height" V="200" />
    <P N="depth" V="300" />
</O>

<O N="Child" T="Project">
    <O T="Group" Extends="Parent" Override="1">
        <P N="width" V="150" />  <!-- Override only width -->
        <!-- height=200 and depth=300 inherited from Parent -->
    </O>
</O>

Result:

Child has:
- width = 150 (overridden)
- height = 200 (inherited)
- depth = 300 (inherited)

Multiple Parameter Override

<O N="Parent" T="Project">
    <P N="a" V="1" />
    <P N="b" V="2" />
    <P N="c" V="3" />
    <P N="d" V="4" />
</O>

<O N="Child" T="Project">
    <O T="Group" Extends="Parent" Override="1">
        <P N="a" V="10" />  <!-- Override a -->
        <P N="c" V="30" />  <!-- Override c -->
        <!-- b=2 and d=4 inherited -->
    </O>
</O>

Result:

Child has:
- a = 10 (overridden)
- b = 2 (inherited)
- c = 30 (overridden)
- d = 4 (inherited)

Override Named Object (Complete Replacement)

When you override a named object from the parent, you must redefine all parameters - nothing is inherited from the parent's version of that object.

Syntax

<O N="Parent" T="Project">
    <O N="Config" T="Group">
        <P N="param1" V="..." />
        <P N="param2" V="..." />
    </O>
</O>

<O N="Child" T="Project" Extends="Parent">
    <O N="Config" T="Group" Override="1">
        <!-- Must redefine ALL parameters -->
        <P N="param1" V="..." />
        <P N="param2" V="..." />
    </O>
</O>

Example

<O N="Person" T="Project">
    <P N="age" V="21" />
    
    <O N="Info" T="Group">
        <P N="text" V="I am a person" T="Text" />
        <P N="status" V="active" T="Text" />
    </O>
</O>

<O N="Employee" T="Project" Extends="Person">
    <P N="working_hours" V="8" />
    
    <!-- Override entire Info object -->
    <O N="Info" T="Group" Override="1">
        <P N="text" V="I am a person and an employee" T="Text" />
        <P N="status" V="active" T="Text" />  <!-- Must redefine -->
    </O>
</O>

If you forget to redefine:

<O N="Employee" T="Project" Extends="Person">
    <O N="Info" T="Group" Override="1">
        <P N="text" V="I am a person and an employee" T="Text" />
        <!-- ❌ Missing status - will not be inherited! -->
    </O>
</O>

Result: Employee.Info will only have text, not status.

How to Override Parameters at Top Level

At T="Project" level, parameters cannot be overridden directly. You must:

Group parameters in the parent
Override the group in the child

Wrong Approach

<!-- ❌ Wrong - cannot override parameters directly -->
<O N="Parent" T="Project">
    <P N="width" V="100" />
    <P N="height" V="200" />
</O>

<O N="Child" T="Project" Extends="Parent">
    <P N="width" V="150" />  <!-- This doesn't override! Creates duplicate! -->
</O>

Correct Approach

<!-- ✅ Correct - group parameters, then override group -->
<O N="Parent" T="Project">
    <O N="Dimensions" T="Group">
        <P N="width" V="100" />
        <P N="height" V="200" />
    </O>
</O>

<O N="Child" T="Project" Extends="Parent">
    <O N="Dimensions" T="Group" Override="1">
        <P N="width" V="150" />
        <P N="height" V="200" />  <!-- Must redefine all -->
    </O>
</O>

Override Summary Table

Override Location

Syntax

Must Redefine All?

Use Case

At Extends level

<O T="Group" Extends="Parent" Override="1">

❌ No - only what you define

Change few parameters

Named object

<O N="Config" T="Group" Override="1">

✅ Yes - all parameters

Replace entire object

Quick Decision Guide

Want to change 1-2 parameters?

<O T="Group" Extends="Parent" Override="1">
    <P N="param1" V="new_value" />  <!-- Only override what you need -->
</O>

Want to completely replace an object?

<O N="ObjectName" T="Group" Override="1">
    <P N="param1" V="..." />  <!-- Redefine all -->
    <P N="param2" V="..." />
</O>

Scoped="1"

Scoped="1" isolates the extended object's namespace.

Rules

Simple rule:

Top level (T="Project"): No Scoped="1"
Everything else: Use Scoped="1"

Top Level (No Scoped)

<O N="Column" T="Project" Extends="Base_Column">
    <!-- No Scoped="1" at top level -->
    <!-- Column inherits Base_Column directly -->
</O>

Inside Objects (Use Scoped)

<O N="MyProject" T="Project">
    
    <!-- Use Scoped="1" when extending inside -->
    <O N="Calculation" T="Group" Extends="HelperCalc" Scoped="1">
        <!-- HelperCalc content is namespaced under "Calculation" -->
    </O>
    
    <!-- Access via dot notation -->
    <P N="result" V="Calculation.some_param" />
</O>

Without Scoped (Top Level)

<O N="Base" T="Project">
    <P N="base_param" V="100" />
</O>

<O N="Child" T="Project" Extends="Base">
    <!-- Inherits base_param directly -->
    <P N="result" V="base_param * 2" />  <!-- Direct access -->
</O>

With Scoped (Inside Object)

<O N="Base" T="Project">
    <P N="base_param" V="100" />
</O>

<O N="MyProject" T="Project">
    
    <O N="Container" T="Group" Extends="Base" Scoped="1">
        <!-- Base content namespaced under "Container" -->
    </O>
    
    <!-- Must use dot notation -->
    <P N="result" V="Container.base_param * 2" />
</O>

When to Extend at Top vs Group Level

Top Level (T="Project"): True Inheritance (IS-A)

Use when child is a type of parent:

<!-- Column IS-A Base_Column -->
<O N="Column" T="Project" Extends="Base_Column">
    <!-- Column has all Base_Column types -->
</O>

<!-- SteelColumn IS-A Column -->
<O N="SteelColumn" T="Project" Extends="Column">
    <!-- SteelColumn has all Column and Base_Column types -->
</O>

When to use:

True inheritance relationship
Child is a specialized version of parent
Type compatibility needed (see Type Inheritance and example below)

Type Compatibility Through Base Classes

A key reason for top-level inheritance is creating type compatibility - allowing input parameters to accept multiple related component types.

The Problem

<!-- We have different girder types -->
<O N="SteelIGirder" T="Project">
    <P N="length" V="10000" Role="Input" />
    <P N="section" V="W36x150" T="Section" Role="Input" />
</O>

<O N="PrecastIGirder" T="Project">
    <P N="length" V="10000" Role="Input" />
    <P N="concrete_strength" V="50" Role="Input" />
</O>

<!-- Cross_Frame works with BOTH girder types -->
<O N="Cross_Frame" T="Project">
    <!-- ❌ Problem: What should T be? -->
    <P N="girder" V="Null" T="???" Role="Input" />
    
    <!-- Can't be just "SteelIGirder" - won't accept PrecastIGirder -->
    <!-- Can't be just "PrecastIGirder" - won't accept SteelIGirder -->
</O>

The Solution: Base Class

Create a base class that both girder types extend:

<!-- Base girder class -->
<O N="BaseGirder" T="Project">
    <P N="length" V="10000" Role="Input" />
</O>

<!-- Steel I-Girder extends BaseGirder -->
<O N="SteelIGirder" T="Project" Extends="BaseGirder">
    <!-- Types: BaseGirder, SteelIGirder -->
    <P N="section" V="W36x150" T="Section" Role="Input" />
</O>

<!-- Precast I-Girder extends BaseGirder -->
<O N="PrecastIGirder" T="Project" Extends="BaseGirder">
    <!-- Types: BaseGirder, PrecastIGirder -->
    <P N="concrete_strength" V="50" Role="Input" />
    <P N="section_type" V="AASHTO_Type_IV" T="Text" Role="Input" />
</O>

<!-- Now Cross_Frame can accept BOTH types -->
<O N="Cross_Frame" T="Project">
    <!-- ✅ Solution: Use BaseGirder type -->
    <P N="girder" V="Null" T="BaseGirder" Role="Input" />
    
    <!-- Can access common exported parameters -->
    <P N="frame_height" V="girder.depth" />
    <P N="connection_width" V="girder.top_flange_width" />
</O>

Usage

<!-- Create girder instances -->
<O N="SteelGirder1" T="SteelIGirder">
    <P N="length" V="12000" />
    <P N="section" V="W36x150" T="Section" />
</O>

<O N="PrecastGirder1" T="PrecastIGirder">
    <P N="length" V="12000" />
    <P N="section_type" V="AASHTO_Type_IV" T="Text" />
</O>

<!-- Cross_Frame accepts BOTH -->
<O N="Frame1" T="Cross_Frame">
    <P N="girder" V="SteelGirder1" T="BaseGirder" />  <!-- ✅ SteelIGirder is-a BaseGirder -->
</O>

<O N="Frame2" T="Cross_Frame">
    <P N="girder" V="PrecastGirder1" T="BaseGirder" />  <!-- ✅ PrecastIGirder is-a BaseGirder -->
</O>

Why This Works

Type hierarchy:
- BaseGirder
  ├── SteelIGirder (types: BaseGirder, SteelIGirder)
  └── PrecastIGirder (types: BaseGirder, PrecastIGirder)

Parameter constraint: T="BaseGirder"
Accepts: Any object with BaseGirder type
Result: Both SteelIGirder and PrecastIGirder accepted ✅

Pattern Summary

When you need a parameter to accept multiple component types:

✅ Create a base class with common interface (exported parameters)
✅ Extend base class to specialized types
✅ Use base class as parameter type: T="BaseClass"
✅ All specialized types now accepted by parameter

Benefits:

Single parameter definition works with multiple component types
Type safety maintained (can't pass unrelated components)
Common interface guaranteed through base class exports
Easy to add new specialized types later

Group Level (T="Group"): Reusing Logic (HAS-A)

Use when object uses parent's calculations:

<!-- ColumnCodeCheck HAS-A compression check -->
<O N="ColumnCodeCheck" T="Project">
    <P N="axial_load" V="1000" Role="Input" />
    
    <O T="Group" Extends="AASHTOCompressionCode" Scoped="1">
        <!-- Reuse AASHTO compression check logic -->
    </O>
    
    <!-- Access results -->
    <P N="passes" V="AASHTOCompressionCode.utilization .LT. 1.0" />
</O>

When to use:

Reusing calculations from library
Not a true inheritance relationship
Want to namespace the extended content

Decision Guide

Scenario

Use

Example

Child is specialized parent

Top level

SteelBeam extends Beam

Using calculation library

Group level

Using AASHTOCode in ColumnCheck

Need type compatibility

Top level

BaseGirder accepted by Cross_Frame

Namespacing needed

Group level

Multiple calculations in same object

Transitive Inheritance

Inheritance is transitive - children inherit from entire ancestor chain.

Example

<O N="Base" T="Project">
    <P N="a" V="1" />
</O>

<O N="Middle" T="Project" Extends="Base">
    <!-- Inherits: a -->
    <P N="b" V="2" />
</O>

<O N="Child" T="Project" Extends="Middle">
    <!-- Inherits: a, b -->
    <P N="c" V="3" />
</O>

Result:

Base has: a
Middle has: a, b
Child has: a, b, c

With Overrides

<O N="Base" T="Project">
    <O N="Config" T="Group">
        <P N="value" V="100" />
    </O>
</O>

<O N="Middle" T="Project" Extends="Base">
    <!-- Override from Base -->
    <O N="Config" T="Group" Override="1">
        <P N="value" V="200" />
    </O>
</O>

<O N="Child" T="Project" Extends="Middle">
    <!-- Override from Middle (which overrode Base) -->
    <O N="Config" T="Group" Override="1">
        <P N="value" V="300" />
    </O>
</O>

Result:

Base.Config.value = 100
Middle.Config.value = 200
Child.Config.value = 300

Process:

Base is created
Middle extends Base, applies overrides
Child extends Middle (with its overrides), applies its own overrides

Type Inheritance

A child inherits all types from its parent.

Type Chain

<O N="Person" T="Project">
    <!-- Types: Person -->
</O>

<O N="Employee" T="Project" Extends="Person">
    <!-- Types: Person, Employee -->
</O>

<O N="Engineer" T="Project" Extends="Employee">
    <!-- Types: Person, Employee, Engineer -->
</O>

Why This Matters

Parameters with type constraints accept compatible types:

<!-- Define components with inheritance -->
<O N="Person" T="Project">
    <P N="age" V="21" />
</O>

<O N="Employee" T="Project" Extends="Person">
    <P N="income" V="25000" />
</O>

<O N="Engineer" T="Project" Extends="Employee">
    <P N="field" V="thermodynamics" />
</O>

<!-- Create instances -->
<O N="John" T="Person" />
<O N="Jane" T="Employee" />
<O N="Bob" T="Engineer" />

<!-- Type-constrained parameters -->
<P N="select_person" V="John" T="Person" />     <!-- ✅ Accepts: Person, Employee, Engineer -->
<P N="select_employee" V="Jane" T="Employee" /> <!-- ✅ Accepts: Employee, Engineer -->
<P N="select_engineer" V="Bob" T="Engineer" />  <!-- ✅ Accepts: Engineer only -->

<!-- Valid assignments -->
<P N="select_person" V="Jane" T="Person" />   <!-- ✅ Employee is-a Person -->
<P N="select_person" V="Bob" T="Person" />    <!-- ✅ Engineer is-a Person -->
<P N="select_employee" V="Bob" T="Employee" /> <!-- ✅ Engineer is-a Employee -->

<!-- Invalid assignments -->
<P N="select_employee" V="John" T="Employee" /> <!-- ❌ Person is not Employee -->
<P N="select_engineer" V="Jane" T="Engineer" /> <!-- ❌ Employee is not Engineer -->

Rule: Child types are compatible with parent types (polymorphism).

Extending Objects Inside Other Objects

You can extend objects at any level, not just top level.

Example: Extending Inside Volume

<O N="SimpleVolume" T="Project">
    <P N="xCoord" V="12" />
    <P N="yCoord" V="24" />
    
    <O T="Volume" X="xCoord" Y="yCoord">
        <O T="Surface">
            <O T="Point" X="0" Y="0" Z="0" />
            <O T="Point" X="10" Y="0" Z="0" />
            <O T="Point" X="10" Y="10" Z="0" />
            <O T="Point" X="0" Y="10" Z="0" />
        </O>
        <O T="Surface">
            <O T="Point" X="0" Y="0" Z="10" />
            <O T="Point" X="10" Y="0" Z="10" />
            <O T="Point" X="10" Y="10" Z="10" />
            <O T="Point" X="0" Y="10" Z="10" />
        </O>
    </O>
</O>

<O N="SimpleVolume2" T="Project">
    <P N="xCoord1" V="545" />
    <P N="yCoord1" V="200" />
    
    <!-- Extend SimpleVolume inside a Group -->
    <O T="Group" Extends="SimpleVolume" Scoped="1" Override="1">
        <!-- Override parameters selectively -->
        <P N="xCoord" V="xCoord1" />
        <P N="yCoord" V="yCoord1" />
    </O>
</O>

Common Patterns

Pattern 1: Base Class with Specializations

<!-- Base column -->
<O N="Base_Column" T="Project">
    <P N="width" V="400" Role="Input" />
    <P N="height" V="3000" Role="Input" />
    
    <O T="Export">
        <P N="area" V="width * width" />
        <P N="volume" V="area * height" />
    </O>
</O>

<!-- Rectangular column -->
<O N="RectangularColumn" T="Project" Extends="Base_Column">
    <P N="depth" V="400" Role="Input" />
    
    <O T="Export">
        <!-- Override area calculation -->
        <O N="Export" T="Export" Override="1">
            <P N="area" V="width * depth" />
            <P N="volume" V="area * height" />
        </O>
    </O>
</O>

<!-- Circular column -->
<O N="CircularColumn" T="Project" Extends="Base_Column">
    <P N="diameter" V="400" Role="Input" />
    
    <O T="Export">
        <!-- Override area calculation -->
        <O N="Export" T="Export" Override="1">
            <P N="area" V="PI * (diameter/2)^2" />
            <P N="volume" V="area * height" />
        </O>
    </O>
</O>

Pattern 2: Reusing Calculation Logic

<O N="BeamDesign" T="Project">
    <P N="moment" V="1000" Role="Input" />
    <P N="section" V="IPE200" T="Section" Role="Input" />
    
    <!-- Reuse AASHTO flexure check -->
    <O N="FlexureCheck" T="Group" Extends="AASHTOFlexure" Scoped="1" Override="1">
        <P N="applied_moment" V="moment" />
        <P N="beam_section" V="section" />
    </O>
    
    <!-- Reuse AASHTO shear check -->
    <O N="ShearCheck" T="Group" Extends="AASHTOShear" Scoped="1" Override="1">
        <P N="applied_shear" V="500" />
        <P N="beam_section" V="section" />
    </O>
    
    <O T="Export">
        <P N="flexure_passes" V="FlexureCheck.utilization .LT. 1.0" />
        <P N="shear_passes" V="ShearCheck.utilization .LT. 1.0" />
        <P N="design_passes" V="flexure_passes .AND. shear_passes" />
    </O>
</O>

Pattern 3: Selective Parameter Override

<O N="StandardBeam" T="Project">
    <P N="length" V="1000" />
    <P N="width" V="200" />
    <P N="height" V="300" />
    <P N="material" V="steel" />
</O>

<O N="CustomBeam" T="Project">
    <!-- Override only length and material -->
    <O T="Group" Extends="StandardBeam" Scoped="1" Override="1">
        <P N="length" V="1500" />
        <P N="material" V="concrete" />
        <!-- width=200 and height=300 inherited -->
    </O>
</O>

Pattern 4: Multiple Base Classes for Modularity

<O N="GeometryBase" T="Project">
    <P N="length" V="1000" />
    <P N="width" V="200" />
    <P N="height" V="300" />
</O>

<O N="MaterialBase" T="Project">
    <P N="density" V="2400" />
    <P N="strength" V="30" />
</O>

<O N="LoadBase" T="Project">
    <P N="dead_load" V="10" />
    <P N="live_load" V="5" />
</O>

<!-- Combine all three -->
<O N="Beam" T="Project" Extends="[GeometryBase, MaterialBase, LoadBase]">
    <O T="Export">
        <P N="volume" V="length * width * height" />
        <P N="weight" V="volume * density" />
        <P N="total_load" V="dead_load + live_load" />
    </O>
</O>

Pattern 5: Version-Specific Extensions

<!-- Use specific versions for stability -->
<O N="BridgeDesign" T="Project" Extends="[OBPBase::v5, OBPHelper::v3, OBPLoads::v2]">
    <!-- Locked to specific versions -->
</O>

<!-- Use latest versions for development -->
<O N="BridgeDesign_Dev" T="Project" Extends="[OBPBase, OBPHelper, OBPLoads]">
    <!-- Uses latest versions -->
</O>

Extends vs Instances

Critical distinction:

Feature

Extends (Inheritance)

T="..." (Instances)

Purpose

Inherit structure

Create instance

Syntax

Extends="Parent"

T="ComponentName"

Use with

Core objects

Library components

Common types

T="Project", T="Group"

User components

Can combine?

❌ No

Extends (Inheritance)

<!-- Inherit from base class -->
<O N="SteelColumn" T="Project" Extends="Base_Column">
    <!-- Inherits all parameters and objects -->
</O>

Use for:

✅ True inheritance (is-a relationship)
✅ Reusing calculation logic
✅ Core objects (T="Project", T="Group", T="Section")

Instances (T="...")

<!-- Create instance of component -->
<O N="MyColumn" T="Column">
    <!-- Creates instance with inputs + exports -->
</O>

Use for:

✅ Creating instances of library components
✅ Building compositions (has-a relationship)
✅ User-developed components

Cannot Combine

<!-- ❌ Invalid - cannot use both -->
<O N="Invalid" T="Cube" Extends="Base_Volume">
    <!-- This doesn't work -->
</O>

Rule: Use either Extends (inheritance) or T="ComponentName" (instance), never both.

Best Practices

1. Avoid Parameter Name Conflicts

❌ Bad - duplicate parameters:

<O N="Base1" T="Project">
    <P N="width" V="100" />
</O>

<O N="Base2" T="Project">
    <P N="width" V="200" />  <!-- Conflict! -->
</O>

<O N="Child" T="Project" Extends="[Base1, Base2]">
    <!-- Ambiguous: which width? -->
</O>

✅ Good - unique parameters:

<O N="GeometryBase" T="Project">
    <P N="geom_width" V="100" />
</O>

<O N="MaterialBase" T="Project">
    <P N="mat_density" V="2400" />
</O>

<O N="Child" T="Project" Extends="[GeometryBase, MaterialBase]">
    <!-- No conflicts -->
</O>

2. Use Scoped="1" Consistently

<!-- ✅ Good - always use Scoped="1" inside objects -->
<O N="MyProject" T="Project">
    <O N="Calc1" T="Group" Extends="Helper1" Scoped="1" />
    <O N="Calc2" T="Group" Extends="Helper2" Scoped="1" />
</O>

<!-- ❌ Bad - inconsistent scoping -->
<O N="MyProject" T="Project">
    <O N="Calc1" T="Group" Extends="Helper1" Scoped="1" />
    <O N="Calc2" T="Group" Extends="Helper2" />  <!-- Missing Scoped -->
</O>

3. Use Versioning for Stability

<!-- ✅ Production - lock versions -->
<O N="ProductionBridge" T="Project" Extends="[OBPBase::v5, OBPHelper::v3]">
    <!-- Stable, predictable behavior -->
</O>

<!-- ✅ Development - use latest -->
<O N="DevBridge" T="Project" Extends="[OBPBase, OBPHelper]">
    <!-- Get latest features -->
</O>

4. Choose Override Strategy Wisely

<!-- ✅ Good - selective override for few changes -->
<O N="CustomBeam" T="Project">
    <O T="Group" Extends="StandardBeam" Scoped="1" Override="1">
        <P N="length" V="1500" />  <!-- Only change length -->
    </O>
</O>

<!-- ✅ Good - object override for complete replacement -->
<O N="CustomBeam" T="Project" Extends="StandardBeam">
    <O N="Geometry" T="Group" Override="1">
        <!-- Replace entire geometry definition -->
        <P N="length" V="1500" />
        <P N="width" V="250" />
        <P N="height" V="400" />
    </O>
</O>

<!-- ❌ Bad - overriding everything defeats purpose -->
<O N="CustomBeam" T="Project" Extends="StandardBeam">
    <O N="Geometry" T="Group" Override="1">
        <P N="length" V="1500" />
        <P N="width" V="200" />
        <P N="height" V="300" />
    </O>
    <O N="Material" T="Group" Override="1">
        <P N="type" V="steel" />
        <P N="grade" V="A36" />
    </O>
    <O N="Loads" T="Group" Override="1">
        <!-- ... -->
    </O>
    <!-- Just define a new component instead -->
</O>

5. Group Parameters for Overriding

<!-- ✅ Good - parameters in groups -->
<O N="Base" T="Project">
    <O N="Dimensions" T="Group">
        <P N="length" V="1000" />
        <P N="width" V="200" />
        <P N="height" V="300" />
    </O>
    
    <O N="Material" T="Group">
        <P N="type" V="steel" />
        <P N="grade" V="A36" />
    </O>
</O>

<O N="Child" T="Project" Extends="Base">
    <!-- Can override groups selectively -->
    <O N="Dimensions" T="Group" Override="1">
        <P N="length" V="1500" />
        <P N="width" V="200" />
        <P N="height" V="300" />
    </O>
</O>

<!-- ❌ Bad - parameters at top level -->
<O N="Base" T="Project">
    <P N="length" V="1000" />
    <P N="width" V="200" />
    <P N="height" V="300" />
    <!-- Cannot override selectively at T="Project" level -->
</O>

6. Document Inheritance Chains

<O N="Engineer" T="Project" Extends="Employee">
    <!-- Engineer extends Employee (which extends Person) -->
    <!-- Inherited from Person: age, name -->
    <!-- Inherited from Employee: working_hours, income -->
    <!-- Added by Engineer: field, position -->
    
    <P N="field" V="thermodynamics" T="Text" Role="Input" />
    <P N="position" V="senior engineer" T="Text" Role="Input" />
</O>

7. Choose Inheritance Level Wisely

<!-- ✅ Top level for true inheritance -->
<O N="SteelColumn" T="Project" Extends="Column">
    <!-- SteelColumn IS-A Column -->
</O>

<!-- ✅ Group level for calculations -->
<O N="ColumnDesign" T="Project">
    <O T="Group" Extends="AASHTOCompression" Scoped="1">
        <!-- ColumnDesign USES compression check -->
    </O>
</O>

8. Keep Inheritance Hierarchies Shallow

<!-- ✅ Good - 2-3 levels -->
Base → Middle → Child

<!-- ⚠️ Risky - too deep -->
Base → L1 → L2 → L3 → L4 → L5 → Child

Deep hierarchies are harder to understand and maintain.

9. Remember Override Rules

Quick reference card:

Override at Extends level:
<O T="Group" Extends="Parent" Override="1">
  <P N="param1" V="..." />  ← Only overrides param1
  ← Other parameters inherited
</O>

Override named object:
<O N="Config" T="Group" Override="1">
  <P N="param1" V="..." />  ← Must define param1
  <P N="param2" V="..." />  ← Must define param2
  ← Nothing inherited from parent's Config
</O>

Common Mistakes

❌ Mistake 1: Missing T Attribute

<!-- ❌ Wrong -->
<O N="Child" Extends="Parent">
    <!-- Missing T attribute -->
</O>

<!-- ✅ Correct -->
<O N="Child" T="Project" Extends="Parent">
    <!-- Has T attribute -->
</O>

❌ Mistake 2: Trying to Override Parameters Directly

<!-- ❌ Wrong - parameters don't have Override attribute -->
<O N="Child" T="Project" Extends="Parent">
    <P N="width" V="150" Override="1" />
</O>

<!-- ✅ Correct - use selective override at Extends level -->
<O N="Child" T="Project">
    <O T="Group" Extends="Parent" Override="1">
        <P N="width" V="150" />
    </O>
</O>

<!-- ✅ Or correct - override parent's group -->
<O N="Parent" T="Project">
    <O N="Config" T="Group">
        <P N="width" V="100" />
        <P N="height" V="200" />
    </O>
</O>

<O N="Child" T="Project" Extends="Parent">
    <O N="Config" T="Group" Override="1">
        <P N="width" V="150" />
        <P N="height" V="200" />
    </O>
</O>

❌ Mistake 3: Forgetting to Redefine All When Overriding Object

<O N="Parent" T="Project">
    <O N="Config" T="Group">
        <P N="a" V="1" />
        <P N="b" V="2" />
        <P N="c" V="3" />
    </O>
</O>

<!-- ❌ Wrong - missing b and c -->
<O N="Child" T="Project" Extends="Parent">
    <O N="Config" T="Group" Override="1">
        <P N="a" V="10" />
        <!-- b and c NOT inherited! -->
    </O>
</O>

<!-- ✅ Correct - redefine all -->
<O N="Child" T="Project" Extends="Parent">
    <O N="Config" T="Group" Override="1">
        <P N="a" V="10" />
        <P N="b" V="2" />
        <P N="c" V="3" />
    </O>
</O>

❌ Mistake 4: Missing Scoped="1" Inside Objects

<!-- ❌ Wrong - missing Scoped="1" -->
<O N="MyProject" T="Project">
    <O T="Group" Extends="Helper">
        <!-- Should have Scoped="1" -->
    </O>
</O>

<!-- ✅ Correct -->
<O N="MyProject" T="Project">
    <O T="Group" Extends="Helper" Scoped="1">
        <!-- Properly scoped -->
    </O>
</O>

❌ Mistake 5: Combining Extends and Instance Creation

<!-- ❌ Wrong - cannot use both -->
<O N="MyObj" T="Cube" Extends="BaseVolume">
    <!-- Invalid - choose one or the other -->
</O>

<!-- ✅ Correct - use Extends -->
<O N="MyObj" T="Project" Extends="BaseVolume">
    <!-- Inheritance -->
</O>

<!-- ✅ Or correct - use instance -->
<O N="MyObj" T="Cube">
    <!-- Instance creation -->
</O>

Summary

Key Concepts

Concept

Description

Extends

Inherit parameters and objects from parent

Multiple

Extends="[A, B, C]" - inherit from multiple parents

Versioning

Extends="Component::v3" - use specific version

Override="1"

Replace inherited content (objects only, not parameters)

Scoped="1"

Namespace extended content (use except top level)

Transitive

Child gets everything from entire ancestor chain

Type inheritance

Child carries all parent types

Override Rules (Critical!)

Override Type

Syntax

Redefine All?

Use When

Extends level

<O Extends="Parent" Override="1">

❌ No - selective

Change few parameters

Named object

<O N="Config" Override="1">

✅ Yes - complete

Replace entire object

When to Use

Use Case

Syntax

Example

True inheritance

Top-level Extends

Column extends Base_Column

Reuse calculations

Group-level Extends

Using AASHTOCode

Multiple bases

Array syntax

Extends="[A, B, C]"

Specific version

Version syntax

Extends="Base::v5"

Change few params

Extends-level Override

<O Extends="X" Override="1">

Replace object

Named Override

<O N="Config" Override="1">

Rules to Remember

Must have T attribute - every object needs T, even with Extends
Override is for objects - cannot override parameters directly
Two override behaviors - selective (Extends level) vs complete (named object)
Cannot combine Extends and T="ComponentName" (instance)
Use Scoped="1" except at top level (T="Project")
Avoid conflicts in multiple inheritance
Version for stability, latest for development
Transitive - inherit entire ancestor chain
Type compatible - child accepted where parent expected

PreviousExport NextParamML Functions Reference

Last updated 24 days ago

Good night

hashtagOverview

hashtagWhat is Extends?

hashtagInheritance: The Underlying Concept

hashtagConceptual Example

hashtagBasic Syntax

hashtagSingle Inheritance

hashtagExample: Person → Employee → Engineer

hashtagMultiple Inheritance

hashtagExample: Multiple Base Classes

hashtagVersioning

hashtagVersion Syntax

hashtagExample

hashtagOverride="1"

hashtagCritical Rules

hashtagOverride at Extends Level (Selective Override)

hashtagSyntax

hashtagExample

hashtagMultiple Parameter Override

hashtagOverride Named Object (Complete Replacement)

hashtagSyntax

hashtagExample

hashtagHow to Override Parameters at Top Level

hashtagWrong Approach

hashtagCorrect Approach

hashtagOverride Summary Table

hashtagQuick Decision Guide

hashtagScoped="1"

hashtagRules

hashtagTop Level (No Scoped)

hashtagInside Objects (Use Scoped)

hashtagWithout Scoped (Top Level)

hashtagWith Scoped (Inside Object)

hashtagWhen to Extend at Top vs Group Level

hashtagTop Level (T="Project"): True Inheritance (IS-A)

hashtagType Compatibility Through Base Classes

hashtagGroup Level (T="Group"): Reusing Logic (HAS-A)

hashtagDecision Guide

hashtagTransitive Inheritance

hashtagExample

hashtagWith Overrides

hashtagType Inheritance

hashtagType Chain

hashtagWhy This Matters

hashtagExtending Objects Inside Other Objects

hashtagExample: Extending Inside Volume

hashtagCommon Patterns

hashtagPattern 1: Base Class with Specializations

hashtagPattern 2: Reusing Calculation Logic

hashtagPattern 3: Selective Parameter Override

hashtagPattern 4: Multiple Base Classes for Modularity

hashtagPattern 5: Version-Specific Extensions

hashtagExtends vs Instances

hashtagExtends (Inheritance)

hashtagInstances (T="...")

hashtagCannot Combine

hashtagBest Practices

hashtag1. Avoid Parameter Name Conflicts

hashtag2. Use Scoped="1" Consistently

hashtag3. Use Versioning for Stability

hashtag4. Choose Override Strategy Wisely

hashtag5. Group Parameters for Overriding

hashtag6. Document Inheritance Chains

hashtag7. Choose Inheritance Level Wisely

hashtag8. Keep Inheritance Hierarchies Shallow

hashtag9. Remember Override Rules

hashtagCommon Mistakes

hashtag❌ Mistake 1: Missing T Attribute

hashtag❌ Mistake 2: Trying to Override Parameters Directly

hashtag❌ Mistake 3: Forgetting to Redefine All When Overriding Object

hashtag❌ Mistake 4: Missing Scoped="1" Inside Objects

hashtag❌ Mistake 5: Combining Extends and Instance Creation

hashtagSummary

hashtagKey Concepts

hashtagOverride Rules (Critical!)

hashtagWhen to Use

hashtagRules to Remember

Overview

What is Extends?

Inheritance: The Underlying Concept

Conceptual Example

Basic Syntax

Single Inheritance

Example: Person → Employee → Engineer

Multiple Inheritance

Example: Multiple Base Classes

Versioning

Version Syntax

Example

Override="1"

Critical Rules

Override at Extends Level (Selective Override)

Syntax

Example

Multiple Parameter Override

Override Named Object (Complete Replacement)

Syntax

Example

How to Override Parameters at Top Level

Wrong Approach

Correct Approach

Override Summary Table

Quick Decision Guide

Scoped="1"

Rules

Top Level (No Scoped)

Inside Objects (Use Scoped)

Without Scoped (Top Level)

With Scoped (Inside Object)

When to Extend at Top vs Group Level

Top Level (T="Project"): True Inheritance (IS-A)

Type Compatibility Through Base Classes

Group Level (T="Group"): Reusing Logic (HAS-A)

Decision Guide

Transitive Inheritance

Example

With Overrides

Type Inheritance

Type Chain

Why This Matters

Extending Objects Inside Other Objects

Example: Extending Inside Volume

Common Patterns

Pattern 1: Base Class with Specializations

Pattern 2: Reusing Calculation Logic

Pattern 3: Selective Parameter Override

Pattern 4: Multiple Base Classes for Modularity

Pattern 5: Version-Specific Extensions

Extends vs Instances

Extends (Inheritance)

Instances (T="...")

Cannot Combine

Best Practices

1. Avoid Parameter Name Conflicts

2. Use Scoped="1" Consistently

3. Use Versioning for Stability

4. Choose Override Strategy Wisely

5. Group Parameters for Overriding

6. Document Inheritance Chains

7. Choose Inheritance Level Wisely

8. Keep Inheritance Hierarchies Shallow

9. Remember Override Rules

Common Mistakes

❌ Mistake 1: Missing T Attribute

❌ Mistake 2: Trying to Override Parameters Directly

❌ Mistake 3: Forgetting to Redefine All When Overriding Object

❌ Mistake 4: Missing Scoped="1" Inside Objects

❌ Mistake 5: Combining Extends and Instance Creation

Summary

Key Concepts

Override Rules (Critical!)

When to Use

Rules to Remember