Can we consider deprecating "name0" functions for "name_empty" functions?

[TonyGravagno]

There are drone functions like box0 and prism0 which generate empty, not-filled structures. The "0" suffix doesn't mean anything. Why not replace that convention with meaningful names, like box_empty and prism_empty?

I recommend an announced phase-out where new functions are introduced and documented in v3.4+. A message can be displayed on the console when these functions are used, but the new _empty functions will be called for the functionality. Then in v4, where we're also removing Canary, the old functions can be entirely disabled, with only the console message to explain why they're not working.

[walterhiggins]

Bear in mind - the functions were given short names for use at the in-game console. I agree the names aren't ideal. Perhaps boxE and prismE ?

[TonyGravagno]

I wasn't thinking about that. There are client and server-side limits to character length of chat and command lines. So this is not a good suggestion.

What do you think about re-channeling the concept? :

1. Not deprecating these valued function names.
2. Adding _empty functions for readability in .js files and recommending '0' functions only for long command-lines.
3. (later) I can create a non-core plugin with the input module that allows multiple lines to be entered and then only executed on a final /jsp execute type of command.

Is there another use case that I'm not considering?

What's on my mind fundamentally is reducing the number of visual, syntactical "bumps" that students encounter as they're learning. We tend to do things like "for( i=0" without thinking much about the historical context of why we use "i" rather than "a" or some other convention. We are also not bothered by variables with a minimal number of vowels like chkHitCnt. But I think each of these little things causes a small "brain ping" on a student that collectively distract or tire them. So when we see box0 and it means "empty box", we have to think about that translation - it's one of those bumps. There are a ton of these already in the language, like semicolons and double == signs that require a mental translation. We can't get around them. Whereas if it says box_empty or even empty_box, there's no need for a brain translation, we've eliminated one of those little mental stutters, and the student's flow moves forward without interruption for just a second longer. I see boxE as being like box0.

Then again, there's nothing wrong with making people think and actually exercising the neurons. :)

So that's where this came from and if you agree with the premise then I'm likely to post more items like this, and request similar notes from the field.

This is similar to my thoughts on providing helper block and item references, where in addition to the Bukkit API names we could provide alternatives. For example: oak_leaves and leaves_oak. That way in a sorted list all of the leaves show up in the same place and a student can quickly search, find, use, and move on. Unfortunately that can be considered as polluting the namespaces, and I've therefore been thinking about that as another non-core helper plugin option.

This all follows the policy of keeping code readable and not clever. But adding simplicity for users always adds complexity to whatever technology is being developed.

Thoughts?