大家好，这里是链客区块链技术问答社区。
链客，专为区块链技术开发者而生，有问必答！
今天给大家介绍一下一种新的编程范式，这会对大家有所帮助。
Vyper的创作为新的编程范式打开了大门。例如，Vyper正在删除类继承以及其他功能，因此可以说Vyper偏离了传统的面向对象编程范例，这很好。
历史上，OOP提供了一种表示现实世界对象的机制。例如，OOP允许实例化可以从person类继承的employee对象。然而，从价值转移和/或智能合约的角度来看，那些渴望功能性编程范式的人会同意，交易性编程绝不适合上述传统的OOP范式。简而言之，交易计算是与现实世界对象分开的世界。例如，你最后一次持有交易或正向链接业务规则的时间是什么时候？
似乎Vyper没有与OOP范例或函数式编程范例完全一致。出于这个原因，在开发的早期阶段，我们能够如此大胆地推出新的软件开发范例吗？一个致力于未来证明区块链可执行代码的人。一个可以防止在不可改变的环境中造成灾难性资金损失的人。区块链革命中经历的过去事件有机地为这一领域的进一步研究和发展创造了新的机会。也许这种研究和开发的结果最终可能导致软件开发的新的不变性范式分类。
装饰符
向@private
@public
@constant
payable
这样的装饰符在每个函数的开头声明。
Private
@private
使合约外部的函数无法访问此函数。
Public
@public
使该函数公开可见和可执行。例如，即使是以太坊钱包也会在查看合约时显示公共函数。
Constant以
@constant
开始的函数不允许状态变量的改变，实际上，如果函数尝试更改状态变量，编译器将拒绝整个程序。如果该函数用于更改状态变量，则不要在函数的开头使用`@constant`。
Payable只有以@payable开头声明的函数才能接收价值。
Vyper明确地实现了装饰符的逻辑。例如，如果一个函数前面有一个`@appay`装饰符和一个`@constant`装饰符，那么Vyper代码编译过程就会失败。当然，这是有道理的，因为常量函数永远不需要参与值的转移。此外，每个Vyper函数必须以`@public`或`@private`装饰符开头，以避免编译失败。同时使用`@public`装饰符和`@private`装饰符的Vyper函数也会导致编译失败。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。