Access modifier proposal

[SPGoding]

Please refer to https://github.com/SPGoding/datapack-language-server/wiki/Access-Modifiers.

THE FOLLOWING CONTENT IS OUTDATED

THE FOLLOWING CONTENT IS OUTDATED

THE FOLLOWING CONTENT IS OUTDATED

Access modifiers can limit the use of several stuff in a set of specific functions. They should be put as annotations in 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" stuff anywhere.

• public means this stuff can be accessed anywhere, which is the behavior of the game. The default modifier will be 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 datapack. If a workspace only has one data pack, then internal will work as the same as public in this workspace.
• within <resource type> [<namespaced ID>...] means this stuff can only be accessed from a set of files.
• 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.

#> 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.

[SPGoding]

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀