Visibility

Visibility lives in the name

A member or Sub-Block's visibility is primarily signaled by its name: myVar is public, _myVar is protected, and __myVar is private.

What visibility actually restricts

Visibility controls which definitions may reference, read, or set a member — it does not prescribe how a renderer manifests it, since renderers always see the entire Canonical BOM regardless of declared visibility.

Visibility may widen, never narrow

A child redeclaration may widen a member's visibility, such as protected to public, but never narrow it — collision checks always use the normalized logical name with visibility prefixes stripped.

Three visibilities on one Block

A single Block can declare properties at all three visibilities side by side, distinguished purely by their names.

<!-- title is public, _internalNote is protected, __cache is private -->
<acme:Widget xmlns="http://blockml.org/bml"
  xmlns:acme="com.acme.example"
  xmlns:core="org.blockml.bml.core"
  xmlns:type="org.blockml.bml.type">

  <baseType>
    core:Block
  </baseType>
  <properties>
    <title type="type:Text" />
    <_internalNote type="type:Text" />
    <__cache type="type:Text" />
  </properties>
</acme:Widget>

Nothing but the name distinguishes these three properties' visibility — title, _internalNote, and __cache read as public, protected, and private purely from their prefixes.

What to carry into the next pages

After this page, readers should be able to tell a member's visibility from its name, before multiplicity closes out the member model with how many values a member may hold.

Continue with multiplicity and collections