语言范式与和原版指令兼容问题

[HsiangNianian]

1. mcfpp 要有面向对象和函数式编程的范型思想以及足够书面化却又能让人一眼看出是哪些 nbt 对象的特性。
2. 要有 nbt 数据类型验证，可以为 1.13 以后的版本建立一个数据类型验证库，同时版本差异也会导致数据类型验证有所差异。
3. 考虑到 mcfpp 是用于 Minecraft 数据包编写，而 Minecraft 数据包通常需要频繁调试和修改，建议将 mcfpp 设计为解释型语言，以便更方便地查看效果并进行调试。当然，具体选择还要根据需求和偏好来决定。

有幸在编译领域摸爬滚打四年，记得当初退坑 mc 还是因为 1.13 指令大改…

多年后看到数据包以及 mcf 能做到这么多事情，感到非常振奋。昨天碰巧发现了 mcfpp 这样一个点子，觉得非常不错，但又发现很容易本末倒置。总之不是很希望 mcfpp 成为那种写小项目显得十分笨重、写大项目又难以维护与阅读的工具。

很不错的点子，加油 （考虑使用 rust 重构吗——） 。

[Alumopper]

解释性语言确实很好，主要是命令本身也是解释性的语言，所以mcfpp做成解释性语言倒应该是水到渠成的事情。只是想尽可能让mcfpp和java相似，语法的较小差异带来的是容易的学习，以及mc和java的联系嘛，也是一个原因。加上一些之后的野心（x

由于我自己就很讨厌那种什么都要搭一个很臃肿的框架的工具，所以我尽力让mcfpp变得简洁。顶层语句就是一个重要的例子。挺有意思的就是，mcfpp几乎是兼容mcf的，没想到吧，只是mcf的命令开头不能加/，而在mcfpp直接使用命令需要加/。之后可能会用其他方案让mcfpp中使用命令也不用加/从而实现完全的兼容

感谢支持！

[rsp4jack]

这个 issue 转换成 dicussion 也许会比较合适一些？

[half-nothing]

解释性语言确实很好，主要是命令本身也是解释性的语言，所以mcfpp做成解释性语言倒应该是水到渠成的事情。只是想尽可能让mcfpp和java相似，语法的较小差异带来的是容易的学习，以及mc和java的联系嘛，也是一个原因。加上一些之后的野心（x

由于我自己就很讨厌那种什么都要搭一个很臃肿的框架的工具，所以我尽力让mcfpp变得简洁。顶层语句就是一个重要的例子。挺有意思的就是，mcfpp几乎是兼容mcf的，没想到吧，只是mcf的命令开头不能加/，而在mcfpp直接使用命令需要加/。之后可能会用其他方案让mcfpp中使用命令也不用加/从而实现完全的兼容

感谢支持！

我觉得直接用/区分原生mc命令并不是一个很好的想法，最好还是使用api统一调用

[Alumopper]

解释性语言确实很好，主要是命令本身也是解释性的语言，所以mcfpp做成解释性语言倒应该是水到渠成的事情。只是想尽可能让mcfpp和java相似，语法的较小差异带来的是容易的学习，以及mc和java的联系嘛，也是一个原因。加上一些之后的野心（x
由于我自己就很讨厌那种什么都要搭一个很臃肿的框架的工具，所以我尽力让mcfpp变得简洁。顶层语句就是一个重要的例子。挺有意思的就是，mcfpp几乎是兼容mcf的，没想到吧，只是mcf的命令开头不能加/，而在mcfpp直接使用命令需要加/。之后可能会用其他方案让mcfpp中使用命令也不用加/从而实现完全的兼容
感谢支持！

我觉得直接用/区分原生mc命令并不是一个很好的想法，最好还是使用api统一调用

主要是捏，降低学习成本，保留原版命令的调用方式，这样只需要了解最最基本的东西就可以使用mcfpp中一些很有用的语法糖。这个主要是借鉴justmcf的思想
保留原版命令也可以在某种程度上兼容mcfunction（？）

[half-nothing]

解释性语言确实很好，主要是命令本身也是解释性的语言，所以mcfpp做成解释性语言倒应该是水到渠成的事情。只是想尽可能让mcfpp和java相似，语法的较小差异带来的是容易的学习，以及mc和java的联系嘛，也是一个原因。加上一些之后的野心（x
由于我自己就很讨厌那种什么都要搭一个很臃肿的框架的工具，所以我尽力让mcfpp变得简洁。顶层语句就是一个重要的例子。挺有意思的就是，mcfpp几乎是兼容mcf的，没想到吧，只是mcf的命令开头不能加/，而在mcfpp直接使用命令需要加/。之后可能会用其他方案让mcfpp中使用命令也不用加/从而实现完全的兼容
感谢支持！

我觉得直接用/区分原生mc命令并不是一个很好的想法，最好还是使用api统一调用

主要是捏，降低学习成本，保留原版命令的调用方式，这样只需要了解最最基本的东西就可以使用mcfpp中一些很有用的语法糖。这个主要是借鉴justmcf的思想 保留原版命令也可以在某种程度上兼容mcfunction（？）

那我都用mcfpp语言了，我这点学习成本还是可以接受的((
可以有两种方式调用，但最好还是要有一个意图明显的api
或者提供一些内置的库来快捷执行一些原版命令
比如 top.mcfpp.vanilla.command 提供tp locate tell team 等命令的执行
同时/直接执行这个也可以作为一个语言特性保留，并不影响

[Alumopper]

解释性语言确实很好，主要是命令本身也是解释性的语言，所以mcfpp做成解释性语言倒应该是水到渠成的事情。只是想尽可能让mcfpp和java相似，语法的较小差异带来的是容易的学习，以及mc和java的联系嘛，也是一个原因。加上一些之后的野心（x
由于我自己就很讨厌那种什么都要搭一个很臃肿的框架的工具，所以我尽力让mcfpp变得简洁。顶层语句就是一个重要的例子。挺有意思的就是，mcfpp几乎是兼容mcf的，没想到吧，只是mcf的命令开头不能加/，而在mcfpp直接使用命令需要加/。之后可能会用其他方案让mcfpp中使用命令也不用加/从而实现完全的兼容
感谢支持！

我觉得直接用/区分原生mc命令并不是一个很好的想法，最好还是使用api统一调用

主要是捏，降低学习成本，保留原版命令的调用方式，这样只需要了解最最基本的东西就可以使用mcfpp中一些很有用的语法糖。这个主要是借鉴justmcf的思想 保留原版命令也可以在某种程度上兼容mcfunction（？）

那我都用mcfpp语言了，我这点学习成本还是可以接受的(( 可以有两种方式调用，但最好还是要有一个意图明显的api 或者提供一些内置的库来快捷执行一些原版命令 比如 top.mcfpp.vanilla.command 提供tp locate tell team 等命令的执行 同时/直接执行这个也可以作为一个语言特性保留，并不影响

肯定会有的哦，mcfpp的一个目的就是顶层高度抽象封装，底层根据不同版本具体实现，一般情况下api不会有大的变动，不会像mojang一周一个快照把数据包全炸了

[half-nothing]

解释性语言确实很好，主要是命令本身也是解释性的语言，所以mcfpp做成解释性语言倒应该是水到渠成的事情。只是想尽可能让mcfpp和java相似，语法的较小差异带来的是容易的学习，以及mc和java的联系嘛，也是一个原因。加上一些之后的野心（x
由于我自己就很讨厌那种什么都要搭一个很臃肿的框架的工具，所以我尽力让mcfpp变得简洁。顶层语句就是一个重要的例子。挺有意思的就是，mcfpp几乎是兼容mcf的，没想到吧，只是mcf的命令开头不能加/，而在mcfpp直接使用命令需要加/。之后可能会用其他方案让mcfpp中使用命令也不用加/从而实现完全的兼容
感谢支持！

我觉得直接用/区分原生mc命令并不是一个很好的想法，最好还是使用api统一调用

主要是捏，降低学习成本，保留原版命令的调用方式，这样只需要了解最最基本的东西就可以使用mcfpp中一些很有用的语法糖。这个主要是借鉴justmcf的思想 保留原版命令也可以在某种程度上兼容mcfunction（？）

那我都用mcfpp语言了，我这点学习成本还是可以接受的(( 可以有两种方式调用，但最好还是要有一个意图明显的api 或者提供一些内置的库来快捷执行一些原版命令 比如 top.mcfpp.vanilla.command 提供tp locate tell team 等命令的执行 同时/直接执行这个也可以作为一个语言特性保留，并不影响

肯定会有的哦，mcfpp的一个目的就是顶层高度抽象封装，底层根据不同版本具体实现，一般情况下api不会有大的变动，不会像mojang一周一个快照把数据包全炸了

别说了，mojang的pack_format从1.19的10蹦到1.20.3的23
直接给我人看傻了
我研究研究编译原理和项目，试试看能不能搞一个(((
很有意思的项目，点个star研究
这下我就有双倍的快乐了

[Alumopper]

有兴趣也可以来一起写啦