Skip to content

Access Modifiers

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

TBD

TBD

TBD

TBD

TBD

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 advancement|function|tag/function|* <id: namespaced ID pattern>

Examples

  • means this stuff can only be accessed from the specified set of files.
  • public means this stuff can be accessed anywhere, which is the behavior of the game. The default modifier is public, so users who don't want this verbose feature won't be bothered by it. Public stuff will be provided in the completions list in the whole workspace.
  • internal means this stuff can only be accessed in the same namespace. If a workspace only has one data pack, then internal will work as the same as public in this workspace.
  • scope is an alias of within.
  • private means this stuff can only be accessed in the same file. Though I don't think any functions could have this modifier (a function with @private and @userannotation?), it's useful for #declare and alias comments. See below for more information.

@internal

Current namespace and default namespace.

#> spgoding:foo
# These function doc comments will be showed in the 
# hover information of a function.
# @user
# @internal
# @input score foo1 params
#        A parameter. The `foo1` will automatically be treated as a private entity declaration.

say hello world

#> 
# A temp tag. This tag won't be provided in the
# completion list of other functions. And if you
# enable the `strictCheck` settings in the config
# file, DHP will report warnings for the use of `temp`
# tag outside of the current function.
#private declare tag temp

#> 
# System related objective. This objective will be
# treated as public by DHP, and will show in the
# completion list everywhere in the workspace because it
# has no access modifiers.
scoreboard objective add system dummy

#> 
# An arbitrary entity name.
# @within function
#    minecraft:*
#    spgoding:foo
#    spgoding:foo/*
#declare entity haha

For functions, you can write modifiers in their document comments (#1). Because Minecraft treats all functions as public, in order to make everything consistent with the game, the override of functions in different data packs takes procedure over access modifiers in DHP. That says, re-defining a function in a small scope but in a low-priority datapack will certainly not work.

For #alias and #declare comments, you can put some simple access modifiers in front of the literal directly, e.g. #private declare advancement spgoding:foo. However, for within modifier, you need to write them in the doc comment for the comment.

When there are multiple access modifiers for the same resource, the final result is the union of the scopes of all the modifiers.

BTW, entity names / score holders in @input and @output function annotation will be automatically treated as private declarations.

Clone this wiki locally