Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plugin rename #1

Open
z3t0 opened this issue Dec 30, 2015 · 3 comments
Open

plugin rename #1

z3t0 opened this issue Dec 30, 2015 · 3 comments

Comments

@z3t0
Copy link

z3t0 commented Dec 30, 2015

A more generic naming scheme such as voxel-block-* would be useful to designate between adding functionality and adding items/blocks etc.

suggested rename: voxel-block-skyhook

@deathcap
Copy link
Member

#1 voxel-skyhook
voxel/voxel-quarry#9 voxel-quarry
voxel/voxel-fluid#2 voxel-fluid
voxel/voxel-measure#1 voxel-measure
voxel/voxel-workbench#4 voxel-workbench
voxel/voxel-furnace#5 voxel-furnace
voxel/voxel-chest#4 voxel-chest
voxel/voxel-pickaxe#4 voxel-pickaxe
voxel/voxel-pumpkin#6 voxel-pumpkin
voxel/voxel-glass#6 voxel-glass
voxel/voxel-decorative#2 voxel-decorative

On the other hand, I think it's simpler to have a flatter naming scheme (some good philosophy from Python: https://www.python.org/dev/peps/pep-0020/ "flat is better than nested"). The voxel- prefix is useful since it shares a namespace with other modules on npm (although, maybe even that is unnecessary if voxel plugins switch to an independent registry or scoped package names: https://docs.npmjs.com/misc/faq#why-no-namespaces), avoiding naming collisions.

Creating a voxel-block-, voxel-item-, etc., hierarchy would add more information but has disadvantages too:

  • When initially creating a plugin, the question of whether it adds a block or item has to be answered up-front. If the answer changes, to follow the convention the plugin would have to be renamed, but frequent renaming can be expensive in terms of maintenance (updating dependent projects, updating links, documentation, tests, registry, and so on). Some of the modules clearly are only for items or blocks, but others may not be always so well-defined: voxel-chest right now adds a chest block, but I could see mobile chests (items) would be an interesting enhancement, possibly fitting into the scheme of the plugin. Same with voxel-workbench, for item workbenches (these seem to be popular in modded Minecraft: http://ftbwiki.org/Pocket_Crafting_Table). voxel-quarry also only adds a block, but the block cannot be obtained through legitimate gameplay yet, so new items may need to be added as constituents of the quarry block's crafting recipe. voxel-furnace is yet another block, but item-based smelting is conceivable, e.g. in Minecraft: http://ftbwiki.org/Minium_Stone#Smelting - if a plugin X adds both items and blocks, this opens the question if whether it should be named voxel-block-X, voxel-item-X, voxel-block-item-X, or just voxel-X.
  • Longer names get truncated by the voxel plugins UI: Truncated plugin names voxel-plugins-ui#3 - a bug for sure, but this ought to be solved before we make the plugin names any longer than they already are. A few are already truncated with the current naming scheme.
  • The more words to read and write, makes it slower to type and cognitively understand. Not just in programming new code but also reading it, overly-long names can become too cumbersome. The essence of this plugin is really just "skyhook", I'd name it that but "voxel-skyhook" is a concession to us leveraging the shared namespace of the NPM modules registry. Granted brevity can be taken too far, but I'd wager verbosity is more of a danger. I like much of this advice: https://www.goodreads.com/work/quotes/35832-the-elements-of-style "omit needless words". If the extra words are necessary they should be added, but if not then I think it's best to carefully consider whether the value they bring is worth the potential disadvantages.

@deathcap
Copy link
Member

Some relevant recent developments:

  • npm scoped packages: https://docs.npmjs.com/getting-started/scoped-packages - allows @scope/project-name, so could use for example @voxel/skyhook instead of voxel-skyhook (may or may not be a good idea; voxel-skyhook seems simpler to me)
  • voxel-plugins 0.5.0+ includes Less magic in voxel-plugins require() plugin loading voxel-plugins#8 - which allows separating the plugin name from the module name, could use something like loaders: {skyhook: require('voxel-skyhook')}, so the module on npm is fully qualified (voxel-skyhook) but it is more succinct (skyhook) within the voxel.js environment where the voxel- prefix is redundant

@deathcap
Copy link
Member

Another point, package.json keywords can be used to help organize plugins - currently: "voxel", "plugin", and a few also have the "block" keyword. This is more flexible and allows for further expansion versus embedding it in the module name. Plugins adding items can add the "item" keyword, or both, as needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants