Skip to content

Access Modifiers

Jump to bottom
SPGoding edited this page Aug 14, 2020 · 5 revisions

Access modifiers can limit the use of certain resources in a set of specific files. They should be put as annotations in IMP-Doc comments.

All of these access modifiers will only be used by DHP for providing completions and diagnostics. If your project is large enough and you don't want your completion list to be filled with hundreds of items, you can use this feature. These modifiers will not affect any of the in-game behavior. You can actually use "private" resources anywhere.

@within

Restrict the visibility of this resource to certain files that match the namespaced ID pattern.

Syntax

  • within <id: namespaced ID pattern>
  • within * <id: namespaced ID pattern>
  • within <type: file type> <id: namespaced ID pattern>

File Type

You can see a full list of file types in this page. Only the specified type of files that match the namespaced ID pattern can access to the resource.

Specifying * or not specifying file type at all results in allowing any types of files that match the pattern to access the resource.

Namespaced ID Pattern

A namespaced ID pattern is really similar to a namespaced ID. The difference is that you can use certain wildcards in it:

  • ?: Represents an arbitrary character that matches [a-z0-9_\-\.].
  • *: Represents 1 or more characters that matches [a-z0-9_\-\.].
  • **: Represents any amount (including 0) of any characters (including : and /).

Some examples of the namespaced ID pattern:

  • spgoding:foo: Matches spgoding:foo.
  • spgoding:ba?: Matches spgoding:bar and spgoding:baz, but not spgoding:foo.
  • spgoding:*/qux: Matches spgoding:foo/qux and spgoding:bar/qux, but not spgoding:abc nor spgoding:qux.
  • spgoding:**/foo: Matches spgoding:foo, spgoding:bar/foo, and spgoding:bar/qux/foo.
  • spgoding:**: Matches any files that is under the spgoding namespace.
  • **: Matches everything.

Examples

#> spgoding:foo
# This function can be accessed from any files under the `example` namespace.
# @within example:**

#> spgoding:foo
# This function can be accessed from any files under the `example` namespace.
# @within * example:**

#> spgoding:foo
# This function can only be accessed from functions under the `example` namespace.
# @within function example:**

#> spgoding:foo
# This function can be accessed from both functions and function tags under the `example` namespace.
# @within 
#   function example:**
#   tag/function example:**

@private

Restrict the visibility of this resource to the current file.

Syntax

  • @private

Examples

#>
# This objective can be accessed from the current file.
# @private
scoreboard objectives add foo dummy

#>
# The effect of @private can actually be implemented with @within:
# @within <The ID of the current function file>

@internal

Restrict the visibility of this resource to the same namespace as the current file and the default namespace (minecraft).

Syntax

  • @internal

Examples

#> spgoding:foo
# This function can be accessed from any files under the `spgoding` namespace and the `minecraft` namespace.
# @internal

#> spgoding:foo
# The effect of @internal can actually be implemented with @within:
# @within
#   spgoding:**
#   minecraft:**

@public and @api

No restrictions to the visibility of this resource.

Syntax

  • @public
  • @api

Examples

#> spgoding:foo
# This function can be accessed from everywhere.
# @public

#> spgoding:foo
# The effect of @public can actually be implemented with @within:
# @within **

Default Visibility Config

You can change the default visibility for resources in the config. See datapack.env.defaultVisibility for more information.

Strict Check Configs

You can enable several strict check configs to show diagnostics for undefined resources. See Lint Rules for more information.

Clone this wiki locally