首先 ScriptCore 是 ESS 的 fork

是不是应该说 clone? fork 是基于别人的源码再开发。

干货

我已经改了一些东西了 还有一些半成品

意思是你有 Shopify 源码？

我跟 shopify 的人聊过的，ess 他们生产在用是没错的，至于 mruby 那边，你看过 shopify script 和 ess 用法对比会发现他们肯定是有一套扩展库在里面。我也苦恼了很久在里面，直到我发现，ess 的测试用例都是他们的真实脚本，那么我逆向了他们放在项目里测试用的 mruby 字节码，我就知道了他们是如何设计标准库的。

另外 ess 极其小众，维护这个项目的人几乎不处理社区的 issues（bugbounty 除外，但其实那些修正最终都是提交给 MRuby）。

这个项目我憋了很久，因为 ess 最初的许可证是专利，在我询问半年后回答我他们忘改了...等上游改正后我才大胆的公开我的版本

奥，我看漏眼了，顶楼有写 Shopify 的开源库 https://github.com/Shopify/ess

@jasl

更新了一下性能测试，随便抄了个 fib 的代码，跑了求第 100 项，3ms 可以的，比我原文中描述的快了非常多，可能是 mruby 1.4.1 带来的，我原始的实验好像还是在 1.3 上

@jasl 如果 spawn 一个 ruby，然后 remove 一些 unsafe 的东西，比如 undef File, IO, remove `等等， 会不会更简单一些？

MRI 不好裁剪，mruby 的标准库的粒度细多了，比如元编程在 mruby 里都是一个 gem

@jasl 我看你说 mruby 没有 bigdecimal? 据我所知，bigdecimal 就是 bigint+ 精度，比如 (a,4) 就是 a/10000.0, 那么+,-实现只要对齐就行了，实现就是 bigint 相乘，精度相加，比如 (a,4)(b,2) 就是 (a*b, 4+2),/实现也是类似。mruby 有 bigint 么？

mruby 没有内建 BigDecimal 类型（MRI 这个是标准库的一部分），当然可以实现一套，但是缺点是无法跟 MRI 的 BigDecimal 做直接映射

Shopify 已经基于 mpdecimal 给 mruby 做了一个了，ESS 还有我的 ScriptCore 都内置，但是因为无法直接映射，所以使用的时候得做手动处理一下

@jasl 是 Decimal 类么？稍微试了一下， x = Decimal.new("1515") * Decimal.new("1515") x=x*x*x*x x=x*x*x*x x=x*x*x*x puts x

123827471039368400410635789691185425627549561183592154304459242100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 数字一大就错了。

另外 integer，乘着乘着就变浮点数了，这是 mruby 的特性么？

ps，感觉接下去就比较 specific 了，要不然我去 github 上开个 issue 讨论？

mruby 没有 BigDecimal 类型，mruby Number 和 Float 的长度限制定义在 mruby 源码的常量里，Shopify 实现的 mruby-mpdecimal 的最大长度应该受 mpdecimal 这个 c 库的限制

大 Integer 变浮点数，这个没研究过，mruby 一些行为跟 MRI 不同，主要是面向性能和内存消耗考虑的，毕竟 mruby 可以跑在单片机上

@jasl 那就看看要支持到什么程度了，或者自己实现一套。跟 MRI 做交互的话，序列话反序列化类似 [:bigdecimal,value,scale] ,虽然不知道 msgpack 啥样，反正一个值表示类型，然后再把值和精度 表示上，就可以跟 MRI 做交互了。查了一下 mruby bigint, 一个是https://github.com/chasonr/mruby-bignum, 一个是https://github.com/chasonr/mruby-gmp-bignum/ , 有 gmp support 的。

那些都没有 ESS 自带的完备，另外首先需不需要那么高的技术指标本身就要商榷，我想不到什么场景需要这么大的数字要求，一般数据库能支持的无符号 bigint 才大概 20 位，另外 msgpack 的 integer 最大也是 8 bytes，就算 mruby 支持，不再搞点 trick 还是不行。

沙箱一定要支持 Decimal 是为了算钱用的。

另外做映射并不是不能做，mruby 端的序列化、反序列化要在 C++ 的部分实现，ESS 的沙箱一部分测试不开源的（用了 Shopify 系统的源码做用例），改出来了也不好测试

从 WorkflowCore 的帖子跳转过来。https://ruby-china.org/topics/37555

我对 ScriptCore 的理解是存储一个公式到数据库中，然后可以在代码中执行获取结果。

我在 stackoverflow 上看到两种解决方法

1. 使用 instance_eval（会有安全问题）

function = "(a/b)*100"
a = 25.0
b = 50

instance_eval function
# => 50.0

1. 使用 Gem dentaku，这是一个 math and logic formula parser and evaluator，地址https://github.com/rubysolo/dentaku

require 'dentaku'

a = 25.0
b = 50
function = "(#{a}/#{b})*100"

calculator = Dentaku::Calculator.new
calculator.evaluate(function) # => 50.0

我觉得使用这两种方法就可以解决工作流中条件判断的需求，所以没有太看明白 ScriptCore 跟上述的区别，请指教？

先说 dentaku，你看看他的 contributor 我在做 ScriptCore 之前很早就做了 https://github.com/jasl/dentaku_calculator

其实我解决表达式引擎的最开始就是从他开始的，我给他强化了更友好的错误提示（其实比 ScriptCore 能给出的错误信息友好得多），如果他能满足你的需求，直接用是完全没问题的。

dentaku 很适合简单场景，他的文法类似 Excel 表达式，对于复杂表达式就比较捉急了，我记得过去做知人的时候有的公司的计薪方案复杂的就算用 Ruby 来写，也会特别长。

后来我发现了 Shopify 基于 mruby 的 ESS，我对技术选型的态度是，如果强大的方案没有增加简单需求的复杂度，那么选择强大的方案。还有什么样的表达式能够比 Ruby 表达能力更强呢？这就是我最终选择 mruby 方案的原因

既然已经是基于 Ruby 语言来构建表达式了，那自然就达到类似 instance_eval 的目的了，但差别在于 instance_eval 是和应用共享上下文的，也就是说这里首先有“致命”级别的安全隐患，其次，没法做有效的资源限制，有问题的表达式会拖累 Rails 进程，也就是说这个方案常规而言是严重不推荐的。

感谢回复，我现在想做的审批系统比较轻量级，希望仅仅给客户有限的条件判断（为了让客户觉得 Web 端设计流程非常简单），那 dentaku 应该可以满足我的需求

嗯，你用哪个也都在我的魔爪下

不过我是觉得你用 ScriptCore 别给他讲太多语法就好了...

也对，正好周末再研究一下 ScriptCore